RE: getting on a longer release cycled



Before you change something, you need to have a reason to; this is more so
if you want to change something that is working out pretty well, such as
GNOME's release cycle. I think you'd be hard pressed to find a universally
accepted reason to change GNOME's release cycle.

This leaves the GNOME >2 question unanswered. Because, how can you plan,
code, and test such a major jump in just six months? If teams are already
having problems with 2.x releases... Then how on earth can they manage the
>2 release??

The solution has already been given: separate branches. Develop >2 alongside
maintaining the current 2.x releases, much in the same way the KDE guys are
working on KDE 4 while still updating KDE 3.x. Of course you can (and
should, I think) always set a release plan for >2 while planning the whole
thing; the point is: I think it is completely irresponsible to impose the
same 6 months on >2 as on 2.x releases. I think most of you agree on that
one.

Anyway, all the above is pointless if GNOME, as Havoc pointed out, does not
get going on >2 soon. With Microsoft gearing up for Vista, and KDE for KDE
4, I don't think GNOME can afford to dawdle that much longer.


Thom Holwerda
---
Managing editor at http://www.osnews.com



> -----Original Message-----
> From: desktop-devel-list-bounces gnome org [mailto:desktop-devel-list-
> bounces gnome org] On Behalf Of David Nielsen
> Sent: donderdag 7 september 2006 21:22
> To: desktop-devel-list gnome org
> Subject: Re: getting on a longer release cycled
> 
> tor, 07 09 2006 kl. 11:24 -0700, skrev David Trowbridge:
> > What in particular isn't possible with the 6-month cycle?
> 
> I honestly don't think it's about the cycle length as much as the slight
> fear we seem to have of setting major goals for the project.
> 
> I doubt we can do Topaz within the comfort of our tried and true 6 month
> cycle and we do need to decide what Topaz is going to be at some point.
> As the honorable Jono Bacon put it, he would hate to go to GUADEC 2007
> and have Topaz still be something we talked about rather than actually
> worked on. This is likely to require someone to take the probably
> unappricated position of Topaz direction manager (or Topaz dictator,
> asbestosuit included).
> 
> Basically I think Hub has the right idea but the wrong approach. We need
> to start thinking about what we want and if that requires us to extend
> the cycle, do things in parallel or whichever solution we need then we
> absolutely need to do it.
> 
> - David Nielsen
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]