Repository navigation
Consider using a prefix in the title of backport PRs #23
Description
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.
Activity
brettcannon commentedon Feb 13, 2017
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 commentedon Feb 13, 2017
"cherry-pick for 3.6" sounds good to me. I don't know how can I create email filters for labels though :)
brettcannon commentedon Feb 13, 2017
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 commentedon Feb 13, 2017
Can we have
backport pendinglabel, to identify that the PR should be backported but it hasn't happened yet?Mariatta commentedon Feb 13, 2017
Nvm just read your email to python-dev. So
backport to X.Yis to be removed oncecherry-pick for X.YPR is created.Mariatta commentedon Feb 14, 2017
🤔 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 commentedon Feb 14, 2017
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 commentedon Feb 14, 2017
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 commentedon Feb 14, 2017
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 commentedon Feb 14, 2017
Actually could GH-24 take care of this by including the labels in the title automatically?
berkerpeksag commentedon Feb 14, 2017
I might be wrong, but GH-24 is about sending an email to python-checkins when a PR ws merged.
brettcannon commentedon Feb 14, 2017
And so you want an email at creation instead?
ncoghlan commentedon Feb 18, 2017
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:
Both of those seem really wordy to me, and I think a simple [X.Y] should suffice
ncoghlan commentedon Feb 18, 2017
Examples of that approach:
Mariatta commentedon Mar 18, 2017
This is already recommended in this section of the devguide :)
brettcannon commentedon Mar 20, 2017
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 commentedon Mar 21, 2017
As my understanding,
[3.6]prefix is only for pull request title, not for commit message.Am I right?
berkerpeksag commentedon Mar 21, 2017
Correct. I use it in only PR titles, but other projects use it in commit messages too. See Django for example.