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.
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:
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 _______________________________________________ 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:
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
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.
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