[core-workflow] instructions for cherrypicking a change from master

[Chris Angelico]

On Mon, Oct 10, 2016 at 10:34 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 10 October 2016 at 01:12, Chris Angelico <rosuav at gmail.com> wrote:
>> In my experience, CPython is stable enough that you can sometimes even
>> pick up a patch from *2.7* and apply it to the latest 3.x. (The
>> downside of this is that some files are oddly named, eg longobject.c,
>> which implements what we now call "int".) Between 3.5 and 3.6 it'll be
>> even more common for a patch to apply cleanly, and shortly after a
>> branch is cut (eg current 3.6 -> 3.7), near-certain.
>
> Right, it's mainly when you collide with a refactoring that things get
> painful (e.g. the SSL/TLS rebase in Python 2.7 ran into that).

Makes sense. So it would probably be worth cherry-picking a patch one
branch at a time; I would expect that such code changes, once done,
are reflected in all future branches, so you'd have something like
"3.3-3.4 work this way, and 3.5-3.7 work that way". Should be pretty
obvious once people get started on it.

> In general though, we shouldn't see any more problems with cherry
> picks than we see with forward merges, and there Misc/NEWS is the only
> consistent source of conflicts.

Is Misc/NEWS needed for old branches? If not, the easiest way might be
to simply build the patch without NEWS, then cherry-pick it to all
other branches, and finally add NEWS to the latest branch only.

>> That would be a personal workflow choice, then. +1 on RFC 2119 MUST vs
>> SHOULD usage. IMO the document should specify *one* recommended
>> workflow, because otherwise it's just way too confusing to read; and
>> then by its language, it can clarify which parts you're allowed to
>> diverge from and which not.
>
> A lot of the SHOULDs will be "Use the web-based workflow to review and
> merge changes, since that offloads more of the work to automated
> systems and can be done from any client device".
>
> While there will be cases where local client usage is needed (and
> generating a backport PR will be one of them, unless/until GitHub
> copies GitLab's cherry-pick-in-the-web-UI feature), allowing reviews
> to be done that way is mainly for the benefit of current core devs
> that prefer to do their reviews locally.

Sounds good to me. Those who are comfortable with local tools are
welcome to use them; if you've become as familiar with gitk as I have,
you won't want to give it up. (hgk/'hg view' is a poor clone of gitk,
with a fraction of its power. Don't judge gitk by hgk!) The default
workflow will be the nice simple web-based one, but there are plenty
of equivalents. GitHub will notice that you've pushed all the commits
in a PR and automatically mark it as "Merged", for instance, so you
don't have to worry about going and doing some bookkeeping.

ChrisA