Re: Beyond GCC 3.0: Summing Up

[dewar at gnat dot com]

<<The goal of both doing development and having new gcc major releases
with no regressions [1] is unattainable.  New code always has new bugs.
>>

First of all, that is a generalization that is far from correct.

Second, sure new code may have bugs, but it is not at all the case that
new code will always cause breaks in the existing test suite. Many bugs
are in fact target independent, and will show up if anyone executes the
test suite. Any new development that is reasonabley complex should be
checked against the test suite before being checked in. I think part of
the trouble with gcc is that this procedure is not followed sufficiently
well. It is far better if problems are resolved before checkins than
after. Yes, it makes a bit of a barrier to say that you can't check things
in unless you have run the test suite and it is clean, but in the long
run it is the only way to continue development without things getting
so unstable that people have to spend too much time fighting the 
instabilities. Most certainly we have been able to continue rapid
development at ACT on GNAT in an environbment where 30 engineers have
full write access to the entire tree.

<<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.
>>

I did not have the impression that the reversion would be anything like
that automatic, and I would definitely not support any automatic process.
I have not seen anyone suggest anything like this.

Yes, of course, if a patch breaks things, we try to find out what is
going on. The issue arises if that effort determines that

a) the patch is correct locally

b) but it means that some other part of the code which used to work, at
least in the test suite, now breaks, and we agree that the "proper" fix
is to fix this other part of the code (this is my understanding of what
we mean when we talk of triggering a latent bug).

Now, do we simply leave the code broken, on the grounds that the latent
bug is a new bug that must be fixed? And more specifically, if no one
steps in to fix this code, do we leave it broken indefinitely? 

That's the question, and Mark and I feel that in this situation, if we
cannot get a quick resolution, then we have to revert the original patch,
so that the status quo of the test suite passing on all targets is
reachieved.

Of course this is not absolute either, as I noted in my previous messages,
it depends on how serious the problem is. For example, if the temporary
problem is that we give a horrible error message for something illegal
when we used to give a nice message, that's probably acceptable (it also
depends how important the original patch was too -- if the patch merely 
rearranged some code for aesthetic purposes, it's less important to 
retaiun the original patch than if it fixes something criytical).

THe point of disagreement is that Richard feels that if a correct patch
reveals a latent bug, then it is better to just leave this latent bug
exposed regardless on the grounds that

a) it is easier to work on that bug if it is exposed at the top of the tree

b) there is more pressure on someone (*) to fix it

Though I agree with both of these points, I often conclude that we cannot
tolerate the broken code and must revert the patch.

(*) we often assign problems to someone at ACT to fix, but we have determined
that Mr (or Ms) Someone does not work for ACT, so such an assignment is
ineffective. I suspect that Someone also does not work as a volunteer for
GCC work either :-)