Subject: Re: [bug#27898] [PATCH 1/2] gnu: Use 'modify-phases' syntax.

From: Marius Bakke <[email-masked]>
Date: Thu, 03 Aug 2017 00:54:13 +0200

Leo Famulari <[email-masked]> writes:

> On Wed, Aug 02, 2017 at 10:08:18PM +0200, Marius Bakke wrote:
>> Leo Famulari <[email-masked]> writes:
>> > I agree, wow! Thanks for this. It should help new Schemers to feel more
>> > comfortable editing packages.
>> >
>> > This might be annoying but it should wait until after the core-updates
>> > branch is done and merged into the master branch. I want to minimize the
>> > number of merge conflicts because they are 1) annoying and 2) relatively
>> > opaque when reading the Git history. Marius's suggestion is another good
>> > one, and would help with issues like that.
>> >
>> > But if we were to wait until after core-updates and push it as one
>> > commit, I wouldn't mind. It's up to the two of you and everyone else :)
>> 
>> Yeah I guess the squashed patch is okay. If we delay the patches until
>> after 'staging' and 'python-updates' as well, no merge will be
>> necessary. But it won't be a pretty cherry-pick either, by then.
>
> True, we should not wait *too* long. I think that doing it after
> core-updates and before staging and python-updates could be good
> compromise, because those branches touch a relatively small number of
> modules. WDYT?

I think the least painful path is:

* Merge 'core-updates'.
* Merge to 'staging'.
* <apply these commits>
* Branch 'python-updates' from staging.
* Build staging.

Sounds good? :-)

>> I don't really have a strong opinion either way. But I'd hate to the one
>> resolving potentially 100s of merge conflicts at once ;-) Cherry-picking
>> at least restricts the set of conflicts to these changes.
>
> OTOH, if Kei doesn't have an unsquashed version of this patch, it will
> be annoying to split it up :)

Yeah.