Re: Beyond GCC 3.0: Summing Up

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Alexandre Oliva wrote:

> This is a very good point.  So, how about setting the process as
> follows:
> 
> (i) the proponent of a patch must run a full bootstrap and the
> testsuite on at least one platform.  In case any regressions show up,
> they must be investigated by the proponent, who must justify why it's
> more important to fix the bug than to avoid the regression (this is
> the rule we have in place now)
> 
> (ii) in case a regression shows up on other platforms, a person must,
> in order to propose reverting a patch, take her/himself the burden of
> investigating the problem and advocating for the regressed feature, as
> opposed to the one fixed in the patch.  This is hopefully not much
> more effort than locating the patch that exposed the latent bug.
> 
> Note how (ii) compares with (i): the person who proposes the patch
> (that reverts the other) must justify why it's better to have one
> failure than the other, just like the proponent of the original patch
> had to do.  It's not enough to just say ``this patch broke my port, so
> I'm reverting it.''
> 
> If a resolution is not immediately (24/48 hours) reached, or if the
> person who identifies the patch that exposed the latent bug can't
> determine the actual cause, this person must open a Gnats PR,
> containing the proposed reversion of the patch, so that people who run
> into the problem can fetch the patch and install it until the problem
> is fixed.  Discussion can proceed in the PR, until a resolution is
> made.
> 
> Enters the release manager.  As a release approaches, the release
> manager (or helper volunteers) may have to go over any still-open PRs
> like those, and make a judgment call on whether to revert the original
> patch (which would be a risk in itself, if the original patch has been
> in for a long time) or leave it in the release branch (in case it's
> still there, one can make the point that it clearly wasn't a step in
> the wrong direction).
> 
> In either case, we'd have a PR containing the patch or the reverted
> patch, so that, even if the patch ends up temporarily reverted, it
> remains in an open PR, so it won't be forgotten.

This would have my vote.  It's reasonably symmetric in new patches vs.
fixing new regressions and it includes a reasonable way to fix things
when the release branch is made.

However, I'd like to add the requirement Geoff Keating brought up: For 
really invasive patches (i.e., something other than a change to a
frontend or a single port or an "obvious fix") the testing should be:

> If a contributor only has one platform, it would be OK to test on that
> platform and two embedded targets with simulators.  Most 
> optimiser bugs would be caught by, say, i386-linux bootstrap,
> i386-linux cross to powerpc-eabisim, i386-linux cross to mips64el-elf.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)