[core-workflow] Are the "cherry-pick for *" labels on GitHub useful?

[Mariatta Wijaya]

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 at gmail.com> wrote:

> On 9 May 2017 at 07:42, Brett Cannon <brett at 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 at gmail.com   |   Brisbane, Australia
> _______________________________________________
> core-workflow mailing list
> core-workflow at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170509/2b767b63/attachment.html>