lilypond-devel
[Top][All Lists]
Advanced

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

Re: Make doc broken - 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf


From: David Kastrup
Subject: Re: Make doc broken - 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf
Date: Sat, 22 Oct 2011 16:41:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Fri, Oct 21, 2011 at 08:18:39PM +0100, Peekay Ex wrote:
>> I think 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf is the checkin that
>> breaks make doc.
>
> It's a good thing that I looked at this at 5am, because upon
> examining the commit I unleashed a loud obscenity.  I use the word
> "mao" in real life as well as online; I can count the number of
> times that I've used a curse word within hearing of anybody else
> on one hand.
>
> Mike, please examine the fix carefully:
>   a6a3f2bfa82f7c9e8f7b153a4cb649beaef80c16
>
> In the future, please push to the dev/staging branch.  I'm not
> asking you to check the compilation yourself, nor am I asking you
> to refrain from making "simple" "last-minute" "fixes".  But
> there's been too many (i.e. more than 1 per year) little problems
> like this.
>
> dev/staging will be merged with master at least once every 24
> hours[1] as long as it
> compiles.  Furthermore, I pledge that I will *always* merge from
> dev/staging (if it compiles) before making a release.  So it
> really adds no significant delay to getting your bugfixes+features
> in the hands of users.

Dingdingding.  I don't think dev/staging should be _merged_, only
fast-forwarded (do the merge using --ff-only).  If it is not
forwardable, the dev/staging master should rebase it on master (so that
it becomes fast-forwardable) and submit it to testing (if necessary, by
overwriting dev/staging again).

The problem is that a merge means
a) the particular version to be committed has not been tested.
b) if one patch in the series is bad, the whole merge needs to be
   reverted.  Reverting a merge is _really_ _really_ bad.  After that,
   all changes are gone, but git is of the opinion that it has
   considered all source patches already.  Cherry-picking any of them
   won't help.  The only remedy is reverting the revert, and then
   reverting single patches.  Ouch ouch ouch.

So if one submitter does not want to vouch for the integrity of his
patch series (that every patch will compile), he may commit his patch
series as one merge to dev/staging, and if it needs to be reverted
again, he'll be the one bearing the pain of reverting his merge patch.
But of you merge dev/staging with _independent_ works into mainline, it
will be very hard to undo only parts.

-- 
David Kastrup




reply via email to

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