Core-workflow: Provide labels to help track PRs that need to be cherry-picked

[brettcannon]

The question is what format to use for the labels. Feel free to vote for the format you prefer by leaving an appropriate reaction on the comment.

[brettcannon]

3.6 cherry-pick

[brettcannon]

cherry-pick for 3.6

[brettcannon]

cp into 3.6

[brettcannon]

3.6 cp

[brettcannon]

cherry-pick into 3.6

[brettcannon]

backport to 3.6

[brettcannon]

3.6 backport

[Carreau]

I would have the pending and completed form.
backport to 3.6/backported to 3.6 in particular once you have a backport bot, it can trigger on the labels themselves, and from one to the other which make it obvious is something was missed. It shoudl make the logic a tiny bit simpler as you don't need to synchronize state with GitHub.

One of the label I think I will add on Jupyter repos is "Automatic backport to X.y failed". Because sometime it fails of course.

From experience I spent 2h last week just to make sure all "marked for backport" patches where backported.

[brettcannon]

Yeah, I'm assuming long-term when there isn't a human involved there will be appropriate labels to cover when something has been successfully done by a bot. But as it stands, since this will be a manual process then the simple removal of the label can indicate that the backport occurred.

[Carreau]

Removing the label can make it hard to filter by PR that have been backported. Let say I want to see all PR that went into 3.7, if the label is removed, then it becomes hard filter.

The other possibility is to (also) use milestone and to backport to all version greater than milestone.

[brettcannon]

@Carreau why do you want/need to know what has already been backported? The commit history will have that sort of information as will Misc/NEWS.

[Carreau]

@Carreau why do you want/need to know what has already been backported? The commit history will have that sort of information as will Misc/NEWS.

It's easier to search using the GitHub interface, and auto generate statistics. Misc/NEWS may be incomplete, and commit history is not that easy without cloning the repo. But that's probably my way of using GitHub for now it's likely a decision to please the core devs.

[brettcannon]

One interesting thing I realized is that "backport to 3.5" could mean "backport to only 3.5" or "backport to 3.5 and all intermediate versions". One great perk of the latter interpretation is that a label won't be missing when a new feature branch is created.

If the latter is preferred then the label could be changed to "backport to 3.6 and newer", "backport through 3.6", "backport to 3.6 ...", or simply stay as "backport to 3.6".