lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: In-tree make check fails with lilypond-book include file regtest.


From: David Kastrup
Subject: Re: In-tree make check fails with lilypond-book include file regtest.
Date: Wed, 28 Mar 2012 07:24:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Tue, Mar 27, 2012 at 02:18:18PM -0400, Julien Rioux wrote:
>> I locally reverted your revert and could make, make test and make
>> doc from scratch in the src dir after the fixes that I committed
>> today. Unless there is any objections I will push the revert of the
>> revert to staging.
>
> Please wait a day.  I don't agree with David's revert of your
> commit without understanding why it was happening,

If one understands why something is happening, one can fix the commit
instead of reverting it.

A revert of non-merge commits is cheap to do and easy to revert again.
In this case, the commit in question stopped "make test" in a standard
setup from completing and broke the build of the release as well.  It
did not contain a bugfix, but rather a regtest for a fix: the fix itself
stayed in LilyPond.

The problem was most likely not with the regtest itself (after all, it
passed the out-of-tree tests of both Patchies), but rather with the
infrastructure supporting that kind of multi-file regtest.  That means
that a fix will meddle with infrastructure, making it a good idea to
give it the normal review process, not an expedited emergency one.

Reverting the problematic regtest removed the urgency for getting a fix
in.

When I acted without further communication, it was not done out of a
whim but because the advantages of doing so very much outweighed the
disadvantages in my assessment of the situation, an assessment based on
more than an hour of tests of different constellations involving and not
involving the commit and analyzing its impact.  Julien's timely response
certainly is welcome and alleviates the problem, but it still is not
amiss to give the proposed fix a chance at review without having to
hammer it home.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]