What next?

[Dave Jones]

On Thu, Jun 02, 2005 at 02:55:59AM +0200, Thomas Vander Stichele wrote:
 > Hi,
 > 
 > 
 > > > Once upon a time, seth vidal <skvidal at 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.

Concurrently supporting 3 releases at the same time is already painful
enough. The ability to drop the oldest release once the next test series
is well underway really helps gather momentum to getting that next
release out the door. Being stuck doing errata for older releases kills
you, especially on larger packages.

We decided long ago that keeping all the releases on the same revision
of the kernel was the only way to stay sane and keep on top of bugs
across three releases. However, this adds an additional burden onto
other developers when upstream breaks compatibility with something
or other, and random bits of userspace need updating.
Stretching out the support for older releases means we have to put
more effort into doing this, or spend more effort backporting
cherry-picked patches (hint: at ~4000 changesets a month upstream, this
isn't going to happen).

The only other two alternatives are dropping support for the oldest
release when the time comes, (ie, what we do now) , or just not doing
updates for anything non-critical. This sounds feasible, but still
gets you into the nightmare of having to cherry-pick and backport
patches, and judging from comments in bugzilla when we've done
similar things in the past, users tend not to like having their
bugs closed with 'not critical, upgrade to the next release'.

		Dave