Re: Beyond GCC 3.0: Summing Up

[Bernd Schmidt <bernds at redhat dot com>]

On Sat, 7 Jul 2001, Mark Mitchell wrote:
>
> Reversions
> ==========
>
> Some people thought we should revert things more aggressively than
> I suggested; others less aggressively.  Overall, people agreed that
> reverting offending patches was reasonable.  Gerald pointed out that
> people with write privileges to the offending area of the code should
> be allowed to do reversions, not just people with global write
> privileges.

Let me just go on the record saying that I consider this reversion policy
incredibly broken.  The reason is that when you check in a correct patch,
you have something like a >50% chance of it breaking something, somewhere.

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.

A real-life example: the reload patch I did just before 3.0 which deleted
all USEs generated during reload.  It seemed obvious enough, but the mips
backend does horrible things with its reload_outdi pattern, emitting USEs
of dead (clobbered) registers.  Did the people working on mips investigate
why their backend suddenly broke?  Did they attempt to fix the problem
after I analyzed it (some time after the patch was reverted)?  No on both
counts.  We now have an unfixed bug with bogus USEs being left around, and
totally broken code in the mips backend, and no one is doing anything about
it.

Maybe the problem you are trying to fix is the fact that some people
repeatedly check in large and mostly untested changes with obvious
mistakes.  If so, the real fix should be to give those people a gentle
slap on their hands (temporary reversion of checkin rights? or whatever).
Yes, and revert those bogus patches.  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).


Bernd