Re: Beyond GCC 3.0: Summing Up

[Bernd Schmidt <bernds at redhat dot com>]

On Mon, 9 Jul 2001, Mark Mitchell wrote:

> How would you feel if a new version of the kernel broke a syscall
> or two, but made process invocation faster?  Or if the new version of
> X displayed bitmaps faster, but occasionally locked up when running
> GNOME?  Or if a new web-browser had support for animated GIFs, but
> all JavaScript pages that used to work stopped working?
>
> When that kind of thing happens, it is very frustruating.  As a user,
> I've sometimes had two of something -- and used one version for some
> things and the other for other things.  That drives me crazy in a
> hurry.
>
> What I want to do is make sure that people that download the next
> version of GCC can just use it to do what they did before -- and
> more!

Taken to its logical conclusion, this means we'll stop all development
work and just continue making 3.0.x bugfix releases.
(Maybe we should permanently have two trees, a stable one and an
experimental one?  The interesting question would be what to move
from the latter to the former, and when.)

The goal of both doing development and having new gcc major releases
with no regressions [1] is unattainable.  New code always has new bugs.
We may be able to fix them all for a new major release, but the real
problem is _old_ code that has no real specification, and contains
bugs and invalid (or unfortunate) assumptions that remain hidden only
if the inputs remain undisturbed.  This means that frequently correct
patches break things, even if this fact is inconvenient.

To come back to the start of the discussion: what I object to is an
_automatic_ reversion policy for the mainline.  (Any policy that
could be enforced by a computer isn't intelligent enough :-)  If a
patch that was installed causes a problem, we should at least try to
figure out what's going on, rather than try to sweep it under the
rug as soon as possible.


Bernd

[1] Some regressions we do not even care about.  So what if romp
    doesn't build?