This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0: Summing Up
- To: aoliva at redhat dot com, dewar at gnat dot com
- Subject: Re: Beyond GCC 3.0: Summing Up
- From: dewar at gnat dot com
- Date: Tue, 10 Jul 2001 07:16:43 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org, kenner at vlsi1 dot ultra dot nyu dot edu,mark at codesourcery dot com
<<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?
>>
That's perfectly reasonable. As Mark says, we don't have some automatic
reversion-bot at work here, so any reversion gets discussed. What we do
for GNAT is that we build on every platform every night, and run the
full test suite every night. In the morning we get a full report of the
state of the test suite on every target. There is someone (actually me
most of the time) in charge of examining these results. If there are
any significant regressions, they are flagged and assigned to the
appropriate person to fix. If they cannot be fixed in a reasonable time,
then either we decide that we can live with a temporary new regression for
a while, or we revert the patch. It is relatively unusual to decide to
revert but it does happen sometimes.