Marius Bakke <mbakke@fastmail.com> writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Wed, Aug 02, 2017 at 10:08:18PM +0200, Marius Bakke wrote:
>>> Leo Famulari <leo@famulari.name> 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? :-)

Actually we probably should swap 2 and 3 if we can take the rebuild hit
on 'master'. I don't know how many rebuilds this will cause, but I guess
as long as it's in the three-digit range it should not take too long.