Re: Beyond GCC 3.0: Summing Up

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    Suppose you have person A checking in a correct patch in part X of the
    compiler.  This causes part Y of the compiler, which is doing
    something insane, to fall over.  With our reversion policy, it's
    easiest for person B, who is maintaining Y, just to revert the patch
    without bothering to fix his own code.  The patch may even get
    reverted without B ever knowing there's a problem with Y.

    But let's not cripple everyone's ability to make forward progress.  If
    it becomes too hard to make changes to gcc, people will go elsewhere
    (as it was proven before).

I share these concerns, but would also specifically add that a major problem
with the proposed scheme is that it greatly increases the amount of knowlege
a person needs to have to modify GCC.  If somebody spends a lot of time
learning, say, combine.c and makes a correct change to it but that change
triggers a latent bug in reload.  Is it reasonable for that person to have to
understand reload (perhaps the most complex part of the compiler) in order to
finish their work?  Aside from whether it's reasonable or not, is it actually
going to *happen*?

We want to encourage people with local knowlege to work on the compiler.

My suggestion is that when a patch causes a regression, somebody with global
knowlege of the compiler should determine whether the patch itself is broken
or if it triggered a latent bug.  The policy in both cases should be
different, at least in the case of a contributor who doesn't have that global
knowlege.

I don't have a good solution to the problem, but I am concerned that if we
don't treat latent bugs differently we are going to both drive away new
contributors and not have the high-quality that would be obtained by making
sure the latent bugs get fixed when they are discovered rather than buried.