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.
