Re: GCC-3.3.4 release status report

[Joe Buck <Joe.Buck@synopsys.COM>]

Gabriel Dos Reis wrote:
> | >>   The number of open PRs targetted for 3.3.4 has grown up to 46
> | >> (from 41 last report).

I wrote:
> | > That is a *huge* number of bugs to attempt to fix in the fourth point
> | > release; an attempt to fix even half that number will probably result in
> | > 3.3.4 being less stable than 3.3.3. 

Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:
> | Indeed. My feeling is that way too many patches are going into 3.3.4 without 
> | any analysis as to the risk of them.

Gabriel Dos Reis wrote:
> I believe that is too much a strong statement.  No patch is blindly
> applied to GCC-3.3.4

Of course the patches are not being applied "blindly".  But I've been in
the biz long enough to expect that no matter how careful or skillful the
development team is, if it introduces 10 new bug fixes into a software
system as complex as GCC in a short time, it will introduce at least one
new significant failure (and often a "paper bag" failure, as in you'll
want to put a paper bag over your head if the new bug escapes testing).
In environments where fixes are done under tight deadline pressure the
number gets closer to 4 to 1 (and fortunately GCC does not have such
pressure).  That's why it would be a good idea to scale back your
ambitions, focus only on the truly most important bugs, and allow a long
enough shake-out period to allow time to find the newly introduced
failures before release.

> I could come tomorrow with a release note saying that only two PRs are
> targetted for 3.3.4; I doubt that would make GCC-3.3.4 better than it
> looks now.  I could also come and say I have 100 open PRs for 
> GCC-3.3.4; I doubt it would make GCC-3.3.4 worse than it is now.

The question boils down to how we want to manage point releases.  I think
that the user expectation should be that we see a montonically increasing
quality from x.y.z to x.y.z+1.  To achieve this, we should not be overly
ambitious and try to fix all regressions, though anything that works in
x.y.z and fails in the x.y branch can't be tolerated.  Regressions that
prevent distros from being built are most critical (e.g. 14640).  Almost
everything else can probably wait.

Given the volume of fixes that have gone into 3.3.4 already, I would
advise a long period of freeze, and encourage people to build whole
distros with the compiler on as many platforms as possible.  It should be
rock-solid, but it will inevitably still contain regressions with respect to
2.95.