Re: Gtk/Gnome release schedules

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-02-04 at 11:25, Michael Meeks wrote:
> Hi Havoc,
> 
> On Mon, 2003-02-03 at 05:23, Havoc Pennington wrote:
> > Since not everyone is on gtk-devel-list, I thought I'd point out
> > Owen's 2.4 plan here:
> 
> 	The most intriguing thing to me about the gtk+ 2.4 plan, is that the
> Gnome release plan is essentially hostage to it. ie. there is very
> little point in having a 6 month Gnome release gap that is out of step
> with an 8 month gtk+ release gap.
>
> 	While it is most pleasing that gtk+ is moving to a train schedule, it
> would be really, really good if gtk+ moved to share some of the release
> disciplines that Gnome has. While it is true that Gtk+ already has it's
> own release process - conservatism seems no really good argument against
> a more collaberative process.
> 
> 	Clearly - not having synchronisation between Gtk+ and Gnome releases is
> a pointlessly daft thing to do; eg. new File selector APIs introduced in
> Gtk+ 2.4 may appear after a Gnome 2.4 code-freeze, and thus not be used
> for another ~6 months in stable code etc.

I guess there are two ways synchronization can be taken:

 A) Release simultaneously with GNOME

 B) Release with the same periodicity.

A) I think would be a *bad* thing. It means that GNOME people couldn't
start developing with new GTK+ features until 3 months or so into
the release, at which point the GNOME development for the release
should be mostly _done_.

If anything, the month gap this time between GTK+-2.2.0 and GNOME-2.2.0
release was too short.

Having the same periodicity might be useful goal.

I'm a little skeptical of our ability to do 6 month release schedules
for GTK+ ... even ignoring maintenance (and non-GTK+ stuff that
takes people's time), that's a tight schedule like:

 1 month planning
 3 months hacking
 2 months stabilization

GTK+-2.4 was a release with very defined goals, and yet it took 
9 months.

On the other hand ... 6 month release cycles do seem to be the
goal of a lot of open source projects, so maybe there would be
value trying to be in sync with that.

We'd definitely have to figure out some way of handling maintenance
in a less time-intensive way, though if we were going to do
6 months.

In any case, GTK+-2.4 is _not_ going to be done 2 months
before a ~August 1 GNOME release, so any considerations really
would apply to the GTK+-2.6 release schedule.

> 	It seems there is no fruitful purpose served in having different
> release schedules, and yet the "blindly follow the gtk+ schedule"
> approach doesn't seem reasonable either.
> 
> 	In 'my' ideal world (and of course, it's entirely possible all this has
> been agreed somewhere that I missed already) - the two teams would work
> together as one (hardly tough recognising the huge overlap of
> personell), and would share a commonly agreed process of deadlines, and
> freezes etc.

Well, personnel for GTK+ releases is basically been me for a couple of
years (with some much appreciated assistance from Kristian and others.)
So, I'm not sure I see the overlap... I've been trying to keep the
GNOME release team as informed as possible about the GTK+ release
cycles.

Regards,
                                         Owen

(How many GNOME features depend on specific GTK+ features anyways? 
I can't imagine that it's that large...  people managed to write
sophisticated applications against GTK+-1.2, after all!)