Hi,
> Once upon a time, seth vidal <skvidal(a)phy.duke.edu> said:
> > What about stretching out the dev cycle from 3months dev + 3 months of
> > testing to something more like 6 months of dev + 3 months of testing.
>
> How about deciding what the major goals of the next release should be
> (within reason of course), estimating about how long it should take to
> meet those goals, and then add in whatever else seems reasonable in the
> given time frame?
Because the decision was explicitly made when the Fedora project started
to do releases at regular intervals rather than based on feature-driven
milestones. This is the model Gnome has used with a good bit of success.
I disagree with the request for stretching, and agree with the
comparison with GNOME's model. Look at how Sarge went down.
In contrast, I'd like to propose another idea - keep FC (x-2) alive
until a month after FC (x) comes out. This would make people feel they
don't need to upgrade every six months, but can do it every year, if
they feel it is a real issue. I find it a little silly how currently FC
(x - 2) gets eol'd around the time FC (x) is starting to churn out test
releases.
Thomas
Dave/Dina : future TV today ! -
http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Don't shut your eyes just yet
Don't even open your mouth just yet
Because there's things you've got to see
There's things you won't believe of me
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! -
http://urgent.fm/