This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Beyond GCC 3.0: Summing Up


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]