Diego Novillo wrote: > So, I was doing some archeology on past releases and we seem to be > getting into longer release cycles. With 4.2 we have already crossed > the 1 year barrier.
I think there are several factors here. 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. I also haven't as much time to put in as a developer. For some previous releases, I was the bug-fixer of last resort, fixing many of the critical bugs -- or at least proposing broken patches that goaded others into fixing things. :-) Holidays are over, CodeSourcery's annual meeting is behind us, and I'm almost caught up on the mailing lists. So, I expect do more goading -- but probably not much more coding. Second, I think there are conflicting desires. In reading this thread, 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. RMS has recently suggested that any wrong code bug (whether a regression or not) that applies to relatively common code is a severe embarrassment in a release. Some people want to put more features onto release branches, while others think we're too lax about changes. If there's one thing I've learned from years of being RM, it's that I can't please everyone. :-) In any case, I've intentionally been letting 4.3 stage 1 drag out, because it looks like there's a lot of important functionality coming in, and I didn't want to leave those bits stranded until 4.4. Some folks have suggested that we ought to try to line up FSF releases to help the Linux distributors. Certainly, in practice, the distributors are naturally most focused at the points that make sense in their own release cycles. However, I think it would be odd for the FSF to try to specifically align with (say) Red Hat and Novell releases (which may not themselves always be well-synchronized) at the possible expense of (say) MontaVista and Wind River. And, there are certainly a large number of non-Linux users -- even on free operating systems. In practice, I think that the creation of release branches has been reasonably useful. It may be true that some of the big server Linux distributors aren't planning on picking up 4.2, but I know of other major users who will be using it. Even without much TLC, the currently 4.2 release branch represents a reasonably stable point, with some key improvements over 4.1 (e.g., OpenMP). Similarly, without much TLC, the current 4.1 branch is pretty solid, and substantially better than 4.1.1. So, the existence of the branch, and the regression-only discipline thereon, has produced a useful point for consumers, even though there's not yet a 4.1.2. 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. It may be that not too many people pick up 4.2.0. But, if 4.3 isn't looking very stable, there will be a point when people decide that 4.2.0 is looking very attractive. The worst outcome of trying to do a 4.2.0 release is that we'll fix some things that are also bugs in 4.3; most 4.2 bugs are also in 4.3. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
