Are the "cherry-pick for *" labels on GitHub useful?
Enough people who work on CPython still use email that instead of just using labels to flag PRs as cherry-picks we also edit the title, e.g. a 3.6 cherry-pick will have both a "cherry-pick for 3.6" label and "[3.6]" prepended to the title. My question is whether anyone is actually using the labels? I realize they are somewhat redundant when we are also adding the title part. The labels are also a friction point with cherry-picker.py as the script can't set those automatically like it can the PR title. So I'm thinking that maybe we should drop the labels? Anyone have an opinion or want to say if they use the labels and how they use them?
On 9 May 2017 at 07:42, Brett Cannon <brett@python.org> wrote:
Enough people who work on CPython still use email that instead of just using labels to flag PRs as cherry-picks we also edit the title, e.g. a 3.6 cherry-pick will have both a "cherry-pick for 3.6" label and "[3.6]" prepended to the title.
My question is whether anyone is actually using the labels? I realize they are somewhat redundant when we are also adding the title part. The labels are also a friction point with cherry-picker.py as the script can't set those automatically like it can the PR title. So I'm thinking that maybe we should drop the labels? Anyone have an opinion or want to say if they use the labels and how they use them?
I haven't seen a particular use for them - the "needs backport" ones are useful as a marker for what still needs backporting, but nothing changes in the process based on whether or not a maintenance branch PR is a cherry-pick or not. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Right now I'm only using the cherry-pick labels to verify whether a backport has been done or not, so then I can remove the `needs backport to` label from the original PR. If all of these become automated, then perhaps cherry-pick labels aren't needed. There should still be a bot that removes the `needs backport` label. It will simplify this issue https://github.com/python/bedevere/issues/13 Mariatta Wijaya On Mon, May 8, 2017 at 8:48 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Enough people who work on CPython still use email that instead of just using labels to flag PRs as cherry-picks we also edit the title, e.g. a 3.6 cherry-pick will have both a "cherry-pick for 3.6" label and "[3.6]" prepended to the title.
My question is whether anyone is actually using the labels? I realize
On 9 May 2017 at 07:42, Brett Cannon <brett@python.org> wrote: they
are somewhat redundant when we are also adding the title part. The labels are also a friction point with cherry-picker.py as the script can't set those automatically like it can the PR title. So I'm thinking that maybe we should drop the labels? Anyone have an opinion or want to say if they use the labels and how they use them?
I haven't seen a particular use for them - the "needs backport" ones are useful as a marker for what still needs backporting, but nothing changes in the process based on whether or not a maintenance branch PR is a cherry-pick or not.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On Tue, 9 May 2017 at 10:23 Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Right now I'm only using the cherry-pick labels to verify whether a backport has been done or not, so then I can remove the `needs backport to` label from the original PR.
Sorry, I didn't mean to suggest that I thought the "needs backport to *" labels should go, my question is about the "cherry-pick for *" labels only.
If all of these become automated, then perhaps cherry-pick labels aren't needed.
The "needs backport *" labels will still be needed even in that instance probably for when a backporting PR fails (e.g. merge conflict that requires a human being to resolve).
There should still be a bot that removes the `needs backport` label. It will simplify this issue https://github.com/python/bedevere/issues/13
Which we are actively discussing. :) -Brett
Mariatta Wijaya
On Mon, May 8, 2017 at 8:48 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Enough people who work on CPython still use email that instead of just using labels to flag PRs as cherry-picks we also edit the title, e.g. a 3.6 cherry-pick will have both a "cherry-pick for 3.6" label and "[3.6]" prepended to the title.
My question is whether anyone is actually using the labels? I realize
On 9 May 2017 at 07:42, Brett Cannon <brett@python.org> wrote: they
are somewhat redundant when we are also adding the title part. The labels are also a friction point with cherry-picker.py as the script can't set those automatically like it can the PR title. So I'm thinking that maybe we should drop the labels? Anyone have an opinion or want to say if they use the labels and how they use them?
I haven't seen a particular use for them - the "needs backport" ones are useful as a marker for what still needs backporting, but nothing changes in the process based on whether or not a maintenance branch PR is a cherry-pick or not.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________
core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On 10 May 2017 at 03:23, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Right now I'm only using the cherry-pick labels to verify whether a backport has been done or not, so then I can remove the `needs backport to` label from the original PR.
For that purpose, what's probably more important is the backport PR title pattern of: [X.Y] <whatever> (GH-<PR number>) The fact it's a cherry-pick is implied by the reference to the original PR (also indicated by the git cherry-pick message in the commit body), while the [X.Y] indicates which branch it's for. The labels are also going to convey strictly less information than that, since they won't indicate the original PR number or the cherry-picked commit hash. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
OK then it seems like the there is no real need to apply `cherry-pick for *` anymore? +1 from me for not having to apply `cherry-pick for *` label. I can update cherry_picker.py readme and the devguide, if we're all ok with it :) what's probably more important is the backport PR
title pattern of: [X.Y] <whatever> (GH-<PR number>)
Yes, cherry_picker.py does this for you :) In the devguide though, we've only instructed people to prefix it with [X.Y], but did not mention about `GH-<PR number>`. I'll open an issue. Thanks :) Mariatta Wijaya On Tue, May 9, 2017 at 7:17 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 10 May 2017 at 03:23, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Right now I'm only using the cherry-pick labels to verify whether a backport has been done or not, so then I can remove the `needs backport to` label from the original PR.
For that purpose, what's probably more important is the backport PR title pattern of:
[X.Y] <whatever> (GH-<PR number>)
The fact it's a cherry-pick is implied by the reference to the original PR (also indicated by the git cherry-pick message in the commit body), while the [X.Y] indicates which branch it's for.
The labels are also going to convey strictly less information than that, since they won't indicate the original PR number or the cherry-picked commit hash.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Since everyone who voiced an opinion agreed that the label is unnecessary, I will happily accept your offer to remove it from everything that's relevant, Mariatta. :) On Fri, 12 May 2017 at 23:42 Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
OK then it seems like the there is no real need to apply `cherry-pick for *` anymore?
+1 from me for not having to apply `cherry-pick for *` label.
I can update cherry_picker.py readme and the devguide, if we're all ok with it :)
what's probably more important is the backport PR
title pattern of: [X.Y] <whatever> (GH-<PR number>)
Yes, cherry_picker.py does this for you :)
In the devguide though, we've only instructed people to prefix it with [X.Y], but did not mention about `GH-<PR number>`. I'll open an issue.
Thanks :)
Mariatta Wijaya
On Tue, May 9, 2017 at 7:17 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 10 May 2017 at 03:23, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Right now I'm only using the cherry-pick labels to verify whether a backport has been done or not, so then I can remove the `needs backport to` label from the original PR.
For that purpose, what's probably more important is the backport PR title pattern of:
[X.Y] <whatever> (GH-<PR number>)
The fact it's a cherry-pick is implied by the reference to the original PR (also indicated by the git cherry-pick message in the commit body), while the [X.Y] indicates which branch it's for.
The labels are also going to convey strictly less information than that, since they won't indicate the original PR number or the cherry-picked commit hash.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Brett Cannon -
Mariatta Wijaya -
Nick Coghlan