Core-workflow: Consider using a prefix in the title of backport PRs

[berkerpeksag]

Can we use a prefix like [backport to X.Y] or [3.6] for backport PRs? For example:

[backport to X.Y] bpo-1234: Fix comment in tokenizer.c

This way we can easily see which PRs are backports on GitHub and we can also set appropriate email filters.

[brettcannon]

I think appropriate labels would be better, otherwise we have to remember what the format is while a label is just right there and labels are more searchable.

Since we have "backport to 3.6" we could add "cherry-pick for 3.6" for PRs which are an actual backport. Does that sound reasonable?

[berkerpeksag]

"cherry-pick for 3.6" sounds good to me. I don't know how can I create email filters for labels though :)

[brettcannon]

Ah, that's why you want the prefix in the title. 😉 I've gone ahead and added the appropriate labels so we can give them a try and see how it works out.

[Mariatta]

Can we have backport pending label, to identify that the PR should be backported but it hasn't happened yet?

[Mariatta]

Nvm just read your email to python-dev. So backport to X.Y is to be removed once cherry-pick for X.Y PR is created.

[Mariatta]

🤔 I realize that @berkerpeksag still wants to be able to filter out the backport emails.
Is [backport to X.Y] still the desired prefix in this case? :)

[brettcannon]

The way I read "backport to 3.6" is this needs to be backported _to_ 3.6, not that it's a backport _for_ 3.6. So if we do decide to drop the labels and go with title prefixes I would argue for [backport for 3.6] or [cherry-pick for 3.6] or [cp for 3.6].

[berkerpeksag]

All of your suggestions look good to me, @brettcannon. The reason I prefer title prefixes is that it's easy to notice backport PRs without using GitHub UI.

See the attached screenshot. Both of them backport PRs (for 3.5 and 3.6 branches) with almost same title so it's a little bit hard to notice the difference :)

[brettcannon]

Then try both labels and prefix for a month and see which one ends up being useful. And to unify with the labels let's go with [cherry-pick for 3.6].

[brettcannon]

Actually could GH-24 take care of this by including the labels in the title automatically?

[berkerpeksag]

I might be wrong, but GH-24 is about sending an email to python-checkins when a PR ws merged.

[brettcannon]

And so you want an email at creation instead?

[ncoghlan]

Another nice thing about issue title notations, is that then a bot can automatically add the label :)

The two prefixes I've seen so far are:

BackportXY
[cherry-pick for X.Y]

Both of those seem really wordy to me, and I think a simple [X.Y] should suffice

[ncoghlan]

Examples of that approach:

• https://github.com/python/cpython/pull/153
• https://github.com/python/cpython/pull/154

[Mariatta]

This is already recommended in this section of the devguide :)

[brettcannon]

Since we are now documenting this as a thing to do, I'm closing this (I don't think we can drop the label due to the fact that search for [3.6] does not turn up what you expect; although if people start typing out [cherry-pick for 3.6] we might be able to drop the labels.)

[methane]

As my understanding, [3.6] prefix is only for pull request title, not for commit message.
Am I right?

[berkerpeksag]

As my understanding, [3.6] prefix is only for pull request title, not for commit message.

Correct. I use it in only PR titles, but other projects use it in commit messages too. See Django for example.