Re: Gtk/Gnome release schedules
- From: Owen Taylor <otaylor redhat com>
- To: Michael Meeks <michael ximian com>
- Cc: Havoc Pennington <hp redhat com>, desktop-devel-list gnome org, Gtk Hackers <gtk-devel-list gnome org>, Release Team <release-team gnome org>
- Subject: Re: Gtk/Gnome release schedules
- Date: 04 Feb 2003 12:44:18 -0500
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!)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]