Re: Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

> compilation speed, code quality, error messages, etc.  The testsuite
> is not the goal; it is the means by which we measure that things
> haven't gotten worse.

I agree 100%.

> For me, "no regressions" is only absolute in the case of changes
> that cause the compiler to generate code that yields the wrong
> results where it before generated code that was correct.  Any
> other regressions are relative, and have to be weighed against
> other measures.

Agree again, except that I'd add in "refuse to compile legal code
that was accepted before".  (I wouldn't include "compile illegal
code that was rejected before".)

> If a change causes 2% average better execution
> speed, but one platform fails to build, then my inclination
> would be to accept the change (assuming no other regressions
> and people consider the change architecturally clean), and let
> the people (if any) who work on the target fix the problem.

I wouldn't agree with you in this case, but I understand what you're
saying.

>
> I think the legal term "rebuttable presumption" may be useful.

Yes.  There's no robot here that will be ripping out patches.  Under
my proposal, anyone with write privileges to that part of the code
*could* do it.  If a patch breaks the SPARC, and the SPARC maintainer
doesn't want to rip out the patch, then it might just sit there.
Hopefully, that would be done when the SPARC maintainer wants to work
on a patch.  If that didn't happen in a while, a global maintainer
might decide to remove the patch, after giving the original poster
a chance to fix it.

It might be that we should require a pair of people authorize any
reversion; that would make sure that a rabid anti-regressionist had
to find an ally before running amok.

I am confident that there will be cases that merit an exception, and
there's no reason we can't do that, in the rare cases where it makes
sense.

Certainly, when a new major change goes in, we have to accept
some medium-term breakage.  But, we should minimize that by the other
part of my proposal that required three build/test platforms for
changes that are big.  (Bigness is also subjective, and would be
determined by the common sense of the developer making the change,
and the SC if necessary.)  And, the original poster should still be
responsible for fixing up problems.

The basic problem is that there are tons of changes to GCC, and if
each them makes the compiler better, but breaks just a couple of
things, we quickly end up with a research compiler, not a production
compiler.  In particular, the compiler can do everything, and very
well, but no actual programs actually work and no actual developers
can actually use it.  We have to stem the tide before it begins.

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