@laanwj So what do you think about adding this note to the documentation?

I think it is a good idea to add information about backporting (when to backport, how to backport) to the documentation, but I'm not sure a disconnected note only saying what not to do is the best way.

In this case we could see that the backport was clearly requested, so "when to backport" was easy. "How to backport" was as you commented an automated conflict-free cherry-pick. Which leads me to following idea of text:

Backporting is done whenever the fix needs to be present in a release branch (e.g. a security issue) or on request. If the backport is trivial and can be cherry-picked automatically, just request a "Needs backport" tag for the original issue or PR. If backport needs any conflict resolution, create the PR manually and wait for comments.

The commit message of a backport should additionally contain following two lines in the end:

Github-Pull: #<original issue/PR number>
Rebased-From: <sha checksum of the code already merged into master branch>

What do you think @laanwj ? I am not force-pushing yet and ready to close this PR if needed.

Edit: "add" [a tag] "to" → "request" [a tag] "for"
Edit: Added text from #17159 (comment)
Edit: fixed missing l - "additionally"

Looks good to me, thanks!

Another thing to mention maybe is to only create a backport PR (when necessary) after the original PR was merged into master. This makes sure that the latest version of the code is backported, so makes review easier (no moving target).

Also backport.py script could be mentioned.

@hebasto please have a look at 28537b729 and tell me what you think

Edit: I actually removed the redundant header, see e52ac9c36

I mean adding an example, like #16189.

I mean adding an example, like #16189.

@promag Added. Have a look.

I'd re-write the text to be something like:

Security and bug fixes can be backported from master to release branches.
If the backport is non-trivial, it may be appropriate to open an additional PR,
to backport the change, only after the original PR has been merged.
Otherwise, backports will be done in batches by maintainers.

A backport should contain the following metadata in the commit body:

Github-Pull ...

Also, this PR does not need backporting.

@fanquake Text changed. Have a look.

This looks ok now. @carnhofdaki can you squash.

@fanquake Sure. Thank you for info.