lilypond-devel
[Top][All Lists]
Advanced

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

Re: reformatted GNUmakefile pushed to staging


From: David Kastrup
Subject: Re: reformatted GNUmakefile pushed to staging
Date: Tue, 23 Oct 2012 11:19:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

James <address@hidden> writes:

> Hello,
>
> On 23 October 2012 08:26, David Kastrup <address@hidden> wrote:
>> Werner LEMBERG <address@hidden> writes:
>>
>>> Folks,
>>>
>>>
>>> as discussed some weeks ago, I've now pushed the reformatted
>>> GNUmakefile to staging.  There are only whitespace changes.
>>
>> Is there anything wrong with our review system?  If you feel there is,
>> how about at least posting the patch for review on the list before
>> pushing?
> ...
>
> Should I defer patchy merge? I see that this has been pushed to
> staging and I have just upgraded my main server to Xubuntu 12.10
> (hence the reason nothing has been merged yet). I have to go out for a
> few hours now, so let me know and I can either kick of a merge
> immediately when I get back or put it back on my normal 2 hour cycle.

No need to do that.  I have run my own copy of patchy-merge, and it
failed because of typos in the Makefile, so I backed the change out
again.  While we gain a short breathing pause, perhaps we should revert

commit 2ab98854c8f67c0edf5bc655a45aa6226e2caca9
Author: David Kastrup <address@hidden>
Date:   Tue Mar 20 12:32:10 2012 +0100

    Archive baselines in LILYPOND_BASELINES directory if specified

while we still have time?  I made this change when I was mostly
responsible for running Patchy, and it is incompatible with the current
Patchy caching system.  I don't think anybody except myself has ever
used it.  It may be nice for making quick comparisons against several
test baselines, but it is not really documented and it would seem that
people use their own stuff for that kind of thing.

So it is likely to be dead code by now, and after a reformatting patch
is applied, it will be rather harder to remove again.

-- 
David Kastrup



reply via email to

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