Re: Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

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

>     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.
>
> That's why it's important to carefully figure out what's "buggy code":
> the new patch or some latent bug.

That's definitely important --

> I do agree with your key comment that all we have are volunteers.
> That's why I'm concerned about making it too hard for them.  If we do,
> we'll either have less volunteers, or they will go off and make their
> own playpen, as has happened before.

Sure.  But some of the things that makes it hard are when the compiler
doesn't work, or when they don't see the fruits of their labors in
a release for a long time because the compiler is too buggy to release,
or when they are frustruated that a new release of the compiler draws
fire from its users because it is not as good as people expected.

It's a tradeoff.

One extreme on the spectrum is to let anyone check in anything at
any time.  The other is to automatically test all check-ins with
a full set of regression, conformance, benchmark, and integration tests
on  all platforms we are interested in -- and reject checkins *before*
they go in.

Our current policy is somewhere in-between: you're
supposed to do some tests on one platform, and you're supposed to
get another pair of eyes to look at your code if you're not a
maintainer of the code you're changing.  Note that even this is
more rigorous than our older policy, which didn't require bootstrapping
and testing your changes at all, really -- but nobody is complaining
about the more rigorous policy.  In fact, there seems to be good support
for it, and it has reduced the breakage.  There *was* controversy
about it at the start, though.

The policy I'm proposing is also in-between.  The same rules apply,
but your check-in is provisional; failure of regression-testing triggers
an additional obligation to fix the problem, or remove your change.

One of these policies can't be "right" and the other "wrong"; they're
just different points on the spectrum.  One would work well in some
situations; the other in other situations.  We can speculate all we
want about how horrified our contributors will be, but we can't really
*know* anything until we do it.  If all of our developers run away, or 
threaten to fork, we'll clearly have to switch back!

Why not just give it a try?

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