GCC Status (2004-08-09)

[Mark Mitchell]

Geoffrey Keating wrote:

>mitchell@mail.codesourcery.com writes:
>
>  
>
>>In terms of time frame, I'd like to go to Stage 3 on or about
>>September 5th.  If there are additional LNO changes that have a
>>positive impact on performance, we can consider them after that time.
>>The final GCC 3.5 release date will depend largely on the rate of bug
>>fixing, but early 2005 seems likely at this point.
>>    
>>
>
>I would suggest that if we're going to go into stage 3, but still
>allow patches for compile speed, code quality, and bug fixing, we
>might as well call it stage 2.
>  
>
Problems with compile speed and code quality are bugs.

>I would also strongly suggest that we not go into stage 3 before we've
>decided on *achievable* release criteria.  I would not like to see a
>situation where we go into stage 3 because we've passed an arbitrary
>deadline, and then stay there for many months because of unachievable
>targets for branching.  If we're going to go into stage 3 because of a
>date, we should equally make a branch and a release based on a date;
>if we want to branch/release based on quality goals, then stage 3
>should also have a quality goal.
>  
>
The mechanism we have for advancing quality is to restrict check-ins.  
That is basically the only mechanism we have.  As long as we are in 
stage 2, experience has shown that we will make relatively little 
progress fixing bugs.  It is not until the only way to make progress is 
to fix bugs -- rather than add features -- that we seem to get much 
traction there.  And, even then, a few people tend to fix most of the 
bugs -- including lots that they did not cause.

>I don't think that making a release based on a deadline would be a bad
>thing.
>  
>
I have mixed feelings about this.  I used to agree more with your 
statement, but on balance I think it's too arbitrary.  People expect our 
releases to be good; if we don't fix a common code-generation bug on a 
popular system because nobody gets around to it, we've not done the FSF 
any favors by releasing a flawed compiler.

Some of the distributors do not care much about what is exactly in the 
FSF releases because they tend to modify their releases heavily anyhow; 
other parties do care a lot.  But, the FSF's primary goal is to provide 
a source distribution that people can download and build on their 
systems.  Until/unless the FSF decides that its primary goal with GCC 
releases is to provide a base for distributors to work from, I think 
we're bound to try to produce a release with acceptable quality.

Managing the tradeoff between quality and timeliness is one of my 
central challenges.

>I also have a suggestion about release targets for bugs.  At the
>moment, we target bugs at the next release that we think it could
>possibly be fixed in.  
>
We only do that for regressions, not for all bugs.

>This leads us to having hundreds of bugs
>targetted an the next release, many of which are not important and
>which no-one is working on.
>  
>
I think the current system works OK.  We push back bugs towards the end 
of the release if they're still open and don't seem important.  Judging 
importance is not very easy; and having the regressions there helps me 
see what things I might be able to fix, personally, and also how much 
damage current changes are doing.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com