Re: Beyond GCC 3.0: Summing Up

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 10, 2001, dewar@gnat.com wrote:

> Well I do think so! It is great to "expose" latent bugs *if* they
> get fixed quickly. If not, then there is no choice but to back out
> a change that causes regressions. 

But backing out the change would *also* cause a regression.  The bug
fixed by the patch would then start failing again.  We'd be trading
one failure for another.

Of course, this logic doesn't apply to patches that introduce new
features, as opposed to fixing bugs.  But I have the impression that
most of the patches fix bugs, not introduce the features, so the
strategy of reverting patches because some testcase starts failing,
even if some other testcase had stopped failing, is not reasonable by
itself.  ``No regressions'' means that the reverted patch would also
have to be backed up, because reverting it would also introduce a
regression.  What we need is to weight the bugs, the one addressed in
the patch and the formerly-latent one, and decide whether the patch
should be reverted or not.  It shouldn't be the call of the proponent
of the patch nor of the maintainers of the portion of code in which
the latent bug is: they might very well take the easy course of action
for them, and push for or against the patch.  But whose call would it
be, then?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me