Re: [RFC] Our release cycles are getting longer

[Diego Novillo <dnovillo at redhat dot com>]

Mark Mitchell wrote on 01/25/07 00:09:

> First, I haven't had as much time to put in as RM lately as in past, so
> I haven't been nagging people as much.
>
Sure, but this is a trend that started with 3.1 and it's gotten 
progressively worse.  Granted, we are now dealing with a much bigger 
project and perhaps the amount of engineering cycles has not kept up:

Release		Size (KLOC)
 1.21 1988	   58
 1.38 1990	   87
  2.0 1992	  229
2.8.1 1998	  416
 EGCS 1998	  603
 2.95 1999	  715
  3.0 2001	1,007
  3.1 2002	1,336
  4.0 2005	1,813
  4.1 2006	2,109
  4.2 2007	2,379

> some people want/suggest more frequent releases.  But, I've also had a
> number of people tell me that the 4.2 release cycle was too quick in its
> early stages, and that we didn't allow enough time to get features in --
> even though doing so would likely have left us even more bugs to fix.
>
That's also true.  The duration of our stage1 cycles has gone down quite 
a bit since 3.3.  The data I have for the 3.x releases is a bit 
incomplete and we had a strange 3.2 release which I didn't include 
because we suddenly jumped from branching 3.1 to releasing 3.2 (that was 
the C++ ABI thing, IIRC).  Anyway, here's the data I got from our 
release schedule.  These are the durations of each stage since 3.1

Release		Stage 1	Stage 2	Stage 3	Release
 3.1 2002	0	65	69	212
 3.3 2003	169	1	61	271
 3.4 2004	262	103	93	289
 4.0 2005	172	64	170	288
 4.1 2006	59	74	133	309
 4.2 2007	61	59	216	393

There is some correlation between the length of Stage1 to Stage3.  It's 
as if longer Stage1s lead to shorter Stage3s.  Perhaps we could consider 
lengthening the early stages, which by all accounts are the more "fun", 
and shorten the pain during stage 3.

Long-lived branches are painful to maintain.  If we allow them more time 
to get in mainline, it may help spread the stabilization work during 
stage1 (a lot more exposure).

Another thing we could try again is going into mini-freeze cycles 
spanning 2-3 weeks.  We've done that in the past when mainline was in a 
pathetic state and I think it was helpful.


> Some folks have suggested that we ought to try to line up FSF releases
> to help the Linux distributors.
>
I don't think that's in our best interest.  We can't really help what 
distros do.  The fact is, however, that when distros pick up a specific 
release, that release tends to be pretty solid (e.g. 4.1).

> I don't think that some of the ideas (like saying that you have to fix N
> bugs for every patch you contribute) are very practical.  What we're
> seeing is telling us something about "the market" for GCC; there's more
> pressure for features, optimization, and ports than bug fixes.  If there
> were enough people unhappy about bugs, there would be more people
> contributing bug fixes.
Agreed.  We are now in a featuritis phase.  We still have many marketing 
bullet points that folks want filled in.  I believe this will continue 
for at least a couple more releases.  We are also being pulled from many 
directions at once, our user base is very diverse.

Making the infrastructure more palatable for external folks to get 
involved in development and attract more engineering cycles is probably 
one of our best long term bets.