Re: Beyond GCC 3.0: Summing Up

[Alexandre Oliva <aoliva at redhat dot com>]

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

> If you let developers freely break things, claiming that it must be
> a latent bug (note that often such a claim is based on faith ("I
> know my fix is correct, therefore it must be a latent bug that is
> taking out example xyz") rather than on direct knowledge, since as
> Richard says, the problem may be entirely elsewhere in the compiler),
> then you are going to end up with a huge mess at the point of the next
> release, trying to clear up all these breaks.

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.

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