On 1/23/07, Diego Novillo <[EMAIL PROTECTED]> 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.
Heh. Maybe part of the problem here is that the release manager isn't very actively persuing a release. The latest GCC 4.2 status report is from October 17, 2006, according to the web site. That is already more than 100 days ago.
For 4.3 we have already added quite a bit of infrastructure that is all good in paper but still needs some amount of TLC.
And the entire backend dataflow engine is about to be replaced, too. GCC 4.3 is probably going to be the most experimental release since GCC 4.0...
There was some discussion on IRC that I would like to move to the mailing list so that we get a wider discussion. There's been thoughts about skipping 4.2 completely, or going to an extended Stage 3, etc.
Has there ever been a discussion about releasing "on demand"? Almost all recent Linux and BSD distributions appear to converge on GCC 4.1 as the system compiler, so maybe there just isn't a "market" for GCC 4.2. I don't see any point in an extended Stage 3. People work on what they care about, and we see time and again that developers just work on branches instead of on bug fixes for the trunk when it is in Stage 3. IMHO the real issue with the GCC release plan, is that there is no way for the RM to make people fix bugs. I know the volunteer blah-blah, but at the end of the day many bugs are caused by the people who work on new projects on a branch when the trunk is in Stage 3. Maybe there should just be some rules about accepting projects for the next release cycle. Like, folks with many bugs assigned to them, or in their area of expertise, are not allowed to merge a branch or big patches into the trunk during Stage 1. Not that I *really* believe that would work... But skipping releases is IMHO not really a better idea. Gr. Steven
