Document how to mark commits on master for cherry picking to stable branch

[fingolfin]

Some time ago we decided to backport changes from master to stable-4.9. One drawback of that is that one can easily forget to do so.

In order to help avoid this, @hulpke suggested in PR #2035 that we could add a fixed string somewhere in the commit message. E.g. "Should be backported to stable-4.9". Or just "Backport to 4.9", or "Cherry pick to 4.9".

I suggest we fix a string, then one can search the git commit log for it. Moreover, somebody (probably will end up being me ?!? sigh) could even write a script which automatically checks for all commits (resp. a suitable subset...) on master containing that string whether they were already merged. The script could even automatically prepare a branch with cherry picks of those which are not yet merged; or at least a list of commits to be cherry-picked.

If we decide to do so, we should document this string somewhere were devs can find it. E.g. CONTRIBUTING.md, the Wiki, the dev manual (or all of them)...

Thoughts?

[fingolfin]

Another thing we could do is to add a label "backport to stable" to be used on PRs. That's not necessarily an alternative, but rather complementary. I.e. using a fixed string in the commit message is useful if only some commits in a PR should be cherry picked.

OTOH the label is good if all changes should be ported. I'd then recommend this course: Once a PR with that label gets merged, somebody should cherry pick the changes, either directly to stable, or into a PR against stable. Then immediately remove the "backport to stable" label, and instead add a comment which links to the new PR, or else lists the commit SHA-1s of the cherry-picked commits.

[fingolfin]

I have added a label backport-to-4.9 and begun using it.

[fingolfin]

This should be codified somewhere, eg in the wiki, dev manual, CONTRIBUTING.md

[hulpke]

Just to understand the process:
Someone will go through all PR's for the master branch and check for this label, these PRs then are also applied to to 4.9.

How about changes that are only part of a PR? Should the commit(s) get the additional comment line "backport-to-4.9" (or is another string better) ?

[ChrisJefferson]

I would say, as far as possible, split such a PR into two PRs, the stuff for master+4.9, and the stuff for master.

It should always be possible to split, because of course the stuff for 4.9 has to be applicable by itself to 4.9 :)

If we realise late that part of a PR should be in 4.9 (or not be in 4.9) then we can always do a special case, even by opening a new PR just to apply it to 4.9.

[fingolfin]

Yeah, so effectively, what we have done recently is this: add the backport-to-4.9 label to PRs which are supposed to be backported. Then we regularly look through merged PRs with that label and without "added to release notes" or similar, and backport them -- either via direct push, or via a fresh PR, at the discretion of the person doing this work.

And yeah, ideally, the PR with the backport-to-4.9 label can go 100% into stable-4.9, without being mixed with commits which are only for master.

[fingolfin]

This (and other information about how we do certaing things) should be documented somewhere, e.g. in a Wiki page...