Re: Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

--On Monday, July 09, 2001 09:21:38 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     I agree -- as long as someone is actively working on a patch.  If
>     nobody is working on a patch, then by what mechanism are we going to
>     ensure that we fix the problem before the release?
>
> The same way we "ensure" that *any* problem is fixed before the release:
> by listing it as a bug and trying to persuade somebody to fix it.

A regression isn't just any problem.  Any user who could use the old
version can use the new version -- if it has no regressions.  To the
extent that there are regressions, they cannot, in general.  That
difference is critical to many users.

Given David's observation about the fact that we can only make tarballs
and refuse patches -- everything else is volunteerism -- there are only
two guarantees that we can conceivably attempt to offer users about an 
upcoming release, if we are willing to promise that there will
ever be another release.

  - It will be different from the previous release.

    This is what we have done up until now.  We used your method
    in the GCC 3.0 release, and there were many regressions that
    went unfixed.  Despite the fact that literally hundreds of hours
    were spent by people fixing bugs introduced by other people.

    It would have taken forever to fix all the regressions.

  - It will not contain regressions from the previous release.

    We will fail, due to undetected bugs, but we can get close.
    I think most users would like this choice better.

    We *can* guarantee that there will be no regressions on the GCC
    testsuite on a given set of target platforms.  That goal is
    feasibly attainable.

We cannot go writing buggy code and then hope that we will have the energy 
to fix it later and somehow expect to get unbuggy code. If we are willing 
to check in buggy code, and not fix it in short order, we have to be 
prepared to have constantly buggy code, and expect to have buggy releases.

-- 
Mark Mitchell                mark@codesourcery.comit
CodeSourcery, LLC            http://www.codesourcery.com