Some initial thoughts about 2.4

[Owen Taylor <otaylor redhat com>]

I'm just in the process of making glib-2-2/pango-1-2/gtk-2-2
maintenance branches. While waiting for the tag commands
to complete, I came up with the following.

2.2 post-mortem:

 What went well:

  - Managed to do a short-timescale release. (Slightly
    over 9 months)
  - Got the major planned features (multihead, Xft2) in.
  - Little or no feature creep.
  - Kept the 2.0.x branch well-maintained while doing so.
  - Merging between the two branches went smoothly.
  - Source and binary compatibility made things 
    a lot easier than the 1.1.x or 1.3.x series.

 What could use improvement:
 
  - Timescale planning was inaccurate; the first dates
    that were discussed were for a final release in early 
    September.
  - Not so great public communication about dates, plans, 
    etc, until late in the process.
  - Too much serialization on one person; it would be
    nice to make releases more of a team effort. 
    (This isn't saying that people weren't helping -  
    there was an amazing amount of really useful help - 
    but rather that stuff was waiting because I was
    the only person in the position to look at it.)
  - Ports were playing catchup for GDK changes again.
    (2.4 should have substantially less GDK changes)

Dates:

 2.4 will be a time based release; that is, we'll pick a 
 timescale and base what goes in on that rather than 
 vice-versa.

 A timescale of 8-9 months seems reasonable; that is,
 a final 2.4.0 in late August or early September.

 A rough schedule for a September 1 release would be:

  Februrary 1 - Have proposals for all major features,
                decide what goes in, doesn't
  June 1      - All major features are in
  July 1      - Feature freeze
  August 1    - API/ABI freeze
  September 1 - 2.4.0
 
Possible features: [off the top of my head]

 - File selector (we have to get this one)
 - Combo widget (Kris has made progress here)
 - New action-based menu API (based on James Henstridge's work, most likely)
 - Toolbar improvements
 - GObject private data
 - Full Unicode 3.2 (4.0?) support, including non-BMP portions.
 - GtkModelFilter (Pretty much done in libegg)
 - Make RTL text editing really work (automatic paragraph
   direction, etc.)
 - Height-for-width geometry management. (Define a new interface, 
   support it GtkVBox, GtkLabel woudl be the minimum.)

I want to keep a HTML plan on www.gtk.org with tentative schedules,
notes about major items, etc. (gtk-web module is autoupdate,
so anyone with CVS access can update.)

I think most of the major features proposals have already had some 
writeup, so the main thing that needs doing is collecting the 
bugzilla and mail archive links.

Regards,
                                        Owen