Re: Gtk/Gnome release schedules

[Michael Meeks <michael ximian com>]

Hi Owen,

On Tue, 2003-02-04 at 17:44, Owen Taylor wrote:
> 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

	Yes - that does suck :-) However - there is a flip side, that IMHO
Gnome people wanting to develop new gtk+ features, can end up in a
situation where the next version of gtk+ is frozen / released just as
they are able to work on pushing new features down the stack.

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

	Exactly; however - I think we're still having hangovers from the
massive 1.4 -> 2.0 gap, which caused a good deal of productisation /
packaging woe that hopefully is mostly a one-off, such that people spent
a lot of time in transition during the lifetime of 2.2 and not doing
useful hacking, hopefully that will be less true of 2.4 (?) 

> Having the same periodicity might be useful goal.

	Quite - that's a far, far more reasonable thing to aim for. The point
being again that important 'Gnome' features are in many ways hostage to
gtk+'s schedule[1] thus it seems a collaberatively arrived at gtk+/gnome
schedule / periodicity is in everyone's interest.

> 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:

	Sure; 

> 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.

	Well - I have no answers at all :-) I'm primarily interested in two
things:

	a) The discussion about the release schedules be public,
	   and well informed.
	b) The discussion should mesh sensibly with the gtk+ team, in
	   such a way that there will be on-going co-operation.

> 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.

	Whatever - the principle of working more closely together in future is
what interests me.[2]

> 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.

	That's great :-) it was great to see your excellent document, and nice
to keep 'us' all informed (rather than just the release team),
particularly of new developments such as gtk+ adopting a train release
model.

> (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!)

	Well, poking at your plan for 2.4 things like fbdirect integration and
XCursor support don't add any opportunities. Many other things do: file
selector, new combo widget, new action based menu API, entry
autocompletion etc.

	As for Gtk+-1.2, I think the rather unproductive proliferation of
various sorts of duplicate functionality (eg. tree widgets) required by
the sophisticated applications is not something we want to repeat at any
cost.

	Anyway, very pleased to see the schedule ideas and the discussion, FWIW
I have no particular problems either way, but I think that we should try
to stick to a 6 month timetable on a long term basis, modulo minor phase
adjustment.

	Regards,

		Michael.

[1] - I think most people understand that after the thread.
[2] - sod Just decision making, lets have courts that make decisions
that lead to "Ever Closer Union" ;-), ahem.
-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot