Re: [Gnu-arch-users] GCC v. Arch address@hidden: Regressions on mainline]

[Stephen J. Turnbull]

>>>>> "Tobias" == Tobias C Rittweiler <address@hidden> writes:

    Tobias> For a GCC-like project it probably would not matter
    Tobias> whether or not the build-test-cycle of one day succeeds,
    Tobias> but after a constant failure throughout a longer interval
    Tobias> (say 3 weeks) the PQM should probably send some
    Tobias> notification to responsible persons.

No.  If there is a second failure, that's long enough to prove that
it's not a "non-atomic commit" problem.  All developers who submitted
patches that were integrated during the first failure period should be
notified.  (You could refine this if you could prove their patch was
innocent a priori, eg a file that is not linked to the broken
program.)  If there is a third or later failure, all developers who
submitted patches that were integrated in period n-1 should get a
notification, but they should also be informed that it's an on-going
failure.  This could also be refined by type of patch; a patch
categorized as "documentation" might be given low probability of
having broken the build or caused a test failure (although
syntax-breaking typos can occur in comments or docstrings).

If you're going to let it slide as long as three weeks, the
notification should be of the form (this is both a joke and a strawman
I'm about to knock down):

------------------------------------------------------------------------
PQM: Karma check ... FAILED.  Commit denied!
REASONS:  Your patch #00666 was integrated immediately before
    integration failure http://gcc-builds.gnu.org/build-20040607.html.
    KARMA -= 1
Your patch #00666 was integrated 2 days before
    integration failure http://gcc-builds.gnu.org/build-20040608.html.
    KARMA -= 2
Your patch #00666 was integrated 3 days before
    integration failure http://gcc-builds.gnu.org/build-20040609.html.
    KARMA -= 4
[...]
NOTE: If you were to leave the project today, you would be reborn as a
Visual Basic programmer reassigned to write device drivers in assembly
language for a CPU planned to be released 2 years hence.
------------------------------------------------------------------------

Now, it's obvious why you can't do that; somebody who committed a new
optimization for the PowerPC shouldn't lose karma because a build
fails for the x86 platform for x86-specific reasons.  It's just too
coarse for any of 1000 other scenarios, too.

However, you also shouldn't just let it go with "the programmers
should all be watching the smoketest billboard for red lights".
Somebody working on the lexical module could do something that causes
a failure in a regression test for a particular optimization, but
"that's far away from me".  People will let checking the smoketest
slide for a day of a week; that causes distance, too.  Finally, the
smoketest billboard is impersonal, but a mail that says "your patch
was at the scene of the crime, and you may be requested to appear for
questioning" makes it your business to know whether your patch might
be involved.  Also if the response is immediate, the programmer's
memory of the patch will be fresh.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do