From brett at python.org Mon May 8 17:42:57 2017 From: brett at python.org (Brett Cannon) Date: Mon, 08 May 2017 21:42:57 +0000 Subject: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful? Message-ID: 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Mon May 8 23:48:16 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 9 May 2017 13:48:16 +1000 Subject: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful? In-Reply-To: References: Message-ID: On 9 May 2017 at 07:42, Brett Cannon 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 From mariatta.wijaya at gmail.com Tue May 9 13:23:29 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Tue, 9 May 2017 10:23:29 -0700 Subject: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful? In-Reply-To: References: Message-ID: 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 wrote: > On 9 May 2017 at 07:42, Brett Cannon 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: From brett at python.org Tue May 9 18:42:59 2017 From: brett at python.org (Brett Cannon) Date: Tue, 09 May 2017 22:42:59 +0000 Subject: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful? In-Reply-To: References: Message-ID: On Tue, 9 May 2017 at 10:23 Mariatta Wijaya 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 wrote: > >> On 9 May 2017 at 07:42, Brett Cannon 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: From eric at ericholscher.com Tue May 9 14:33:53 2017 From: eric at ericholscher.com (Eric Holscher) Date: Tue, 9 May 2017 11:33:53 -0700 Subject: [core-workflow] Where to host documentation? (was: Voting on possible subdomains for the devguide) Message-ID: As another note, PEP 545 (https://www.python.org/dev/peps/pep-0545/) requires a lot of changes to how Python generates its documentation. RTD already has support for this (http://docs.readthedocs.io/en/latest/localization.html) and I'd argue this is another classic case of duplicating effort, instead of working together to make the solution that the entire community uses better. I'd love to have the work going towards making Python's i18n story better also help make the community's i18n story better. Cheers, Eric -- Eric Holscher Maker of the internet residing in Portland, Oregon http://ericholscher.com From ncoghlan at gmail.com Tue May 9 22:17:26 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 10 May 2017 12:17:26 +1000 Subject: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful? In-Reply-To: References: Message-ID: On 10 May 2017 at 03:23, Mariatta Wijaya 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] (GH-) 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 at gmail.com | Brisbane, Australia From willingc at willingconsulting.com Tue May 9 23:10:03 2017 From: willingc at willingconsulting.com (Carol Willing) Date: Tue, 09 May 2017 20:10:03 -0700 Subject: [core-workflow] Where to host documentation? (was: Voting on possible subdomains for the devguide) In-Reply-To: References: Message-ID: <5912848B.5000204@willingconsulting.com> Eric Holscher wrote: > > As another note, PEP 545 (https://www.python.org/dev/peps/pep-0545/) > requires a lot of changes to how Python generates its documentation. > RTD already has support for this > (http://docs.readthedocs.io/en/latest/localization.html) and I'd argue > this is another classic case of duplicating effort, instead of working > together to make the solution that the entire community uses better. > I'd love to have the work going towards making Python's i18n story > better also help make the community's i18n story better. > > Cheers, > Eric I think it is wonderful that there is energy and enthusiasm behind translation of documentation. The Django documentation (https://docs.djangoproject.com/ja/1.11/) provides a very nice user experience for different languages. I have to agree with Eric that it would be great to leverage the effort already done by RTD and the Django community. Warmly, Carol > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Sat May 13 02:42:10 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Fri, 12 May 2017 23:42:10 -0700 Subject: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful? In-Reply-To: References:

Message-ID: 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] (GH-) 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-`. I'll open an issue. Thanks :) Mariatta Wijaya On Tue, May 9, 2017 at 7:17 PM, Nick Coghlan wrote: > On 10 May 2017 at 03:23, Mariatta Wijaya > 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] (GH-) > > 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 at gmail.com | Brisbane, Australia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat May 13 15:56:48 2017 From: brett at python.org (Brett Cannon) Date: Sat, 13 May 2017 19:56:48 +0000 Subject: [core-workflow] Are the "cherry-pick for *" labels on GitHub useful? In-Reply-To: References:

Message-ID: 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 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] (GH-) > > > 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-`. I'll open an issue. > > Thanks :) > > > Mariatta Wijaya > > On Tue, May 9, 2017 at 7:17 PM, Nick Coghlan wrote: > >> On 10 May 2017 at 03:23, Mariatta Wijaya >> 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] (GH-) >> >> 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 at gmail.com | Brisbane, Australia >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariatta.wijaya at gmail.com Mon May 15 12:48:37 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Mon, 15 May 2017 09:48:37 -0700 Subject: [core-workflow] Workflow for applying b.p.o patches to GitHub Message-ID: Hi, I'd like to get clarification of the proper workflow for applying patches from b.p.o to GitHub. Technically, one can use patch command, or using hg diff --git, and this will be documented in https://github.com/python/devguide/issues/193 The ideal situation is to have the patch author prepare their own GitHub PR. Most of them have been happy to do this :) However, I've seen situations where the patch author is unable to upload their patch to GitHub: 1. author is no longer active, but we want to apply their patch. 2. author is not caught up with GitHub workflow, and asked someone else to prepare the PR. 3. author refuses to use GitHub, but wants their patch applied anyway. Couple questions: 1. Can anyone prepare the GitHub PR based on the patch? or only core developers? 2. If anyone can prepare the GitHub PR, what do we need in terms of CLA? I prefer not to have to guess on this matter. In the rare situation like bpo-30181, author signed CLA in bpo, but we can't verify it on GitHub since they don't have a GitHub account. How should we go forward with it? Anything else we need to worry about? I'd like to get all of these documented in the devguide. Thanks :) Mariatta Wijaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon May 15 13:13:09 2017 From: brett at python.org (Brett Cannon) Date: Mon, 15 May 2017 17:13:09 +0000 Subject: [core-workflow] Workflow for applying b.p.o patches to GitHub In-Reply-To: References: Message-ID: On Mon, 15 May 2017 at 09:49 Mariatta Wijaya wrote: > Hi, > > I'd like to get clarification of the proper workflow for applying patches > from b.p.o to GitHub. > > Technically, one can use patch command, or using hg diff --git, and this > will be documented in https://github.com/python/devguide/issues/193 > > The ideal situation is to have the patch author prepare their own GitHub > PR. Most of them have been happy to do this :) > > However, I've seen situations where the patch author is unable to upload > their patch to GitHub: > > 1. author is no longer active, but we want to apply their patch. > 2. author is not caught up with GitHub workflow, and asked someone else to > prepare the PR. > 3. author refuses to use GitHub, but wants their patch applied anyway. > > Couple questions: > 1. Can anyone prepare the GitHub PR based on the patch? or only core > developers? > My vote is only core developers because ... > 2. If anyone can prepare the GitHub PR, what do we need in terms of CLA? I > prefer not to have to guess on this matter. > ... I also don't want to guess on this matter either. :) Hopefully Van will be at the conference and we can just ask him how to handle this (otherwise we should just email). > In the rare situation like bpo-30181, author signed CLA in bpo, but we > can't verify it on GitHub since they don't have a GitHub account. How > should we go forward with it? > I think it will depend on how we answer questions 1 & 2. -Brett > > Anything else we need to worry about? > I'd like to get all of these documented in the devguide. > > Thanks :) > > Mariatta Wijaya > _______________________________________________ > 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: From ericsnowcurrently at gmail.com Wed May 24 17:38:40 2017 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 24 May 2017 14:38:40 -0700 Subject: [core-workflow] travis bottleneck at sprints Message-ID: tl;dr Could we temporarily bump our cap on concurrent travis builds during sprints? During the sprints at PyCon we've been running into a serious bottleneck with travis. Having an extra allowance for builds already is great, but during sprints even that gets swamped. I am not sure what projects contribute most to the problem, but I'm pretty sure it isn't CPython (essentially 2 builds per PR). Regardless, with the new workflow this bottleneck significantly impacts the higher pace that usually takes place at sprints. Would it make sense to see if the Travis folks would be willing to bump our limit temporarily during each sprint? -eric From guido at python.org Wed May 24 17:45:38 2017 From: guido at python.org (Guido van Rossum) Date: Wed, 24 May 2017 14:45:38 -0700 Subject: [core-workflow] travis bottleneck at sprints In-Reply-To: References: Message-ID: I've noticed that too; the python/mypy project is also experiencing slow builds (as is mypy/typeshed). I don't know how to contact Travis for this though. On Wed, May 24, 2017 at 2:38 PM, Eric Snow wrote: > tl;dr Could we temporarily bump our cap on concurrent travis builds > during sprints? > > During the sprints at PyCon we've been running into a serious > bottleneck with travis. Having an extra allowance for builds already > is great, but during sprints even that gets swamped. I am not sure > what projects contribute most to the problem, but I'm pretty sure it > isn't CPython (essentially 2 builds per PR). Regardless, with the new > workflow this bottleneck significantly impacts the higher pace that > usually takes place at sprints. Would it make sense to see if the > Travis folks would be willing to bump our limit temporarily during > each sprint? > > -eric > _______________________________________________ > 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 > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu May 25 16:49:28 2017 From: brett at python.org (Brett Cannon) Date: Thu, 25 May 2017 20:49:28 +0000 Subject: [core-workflow] travis bottleneck at sprints In-Reply-To: References: Message-ID: Donald is our contact with Travis, so I've explicitly added him to this email. To give some details: we get 25 concurrent jobs across all the various "official" Python projects on GitHub hosted under the Python, PyPA, and PyCA organizations (which is a substantial bump from what most projects get; see https://travis-ci.com/plans to get an idea of what we're getting for free). CPython itself uses 3 of those with any single PR or merge into a branch (docs, Py_DEBUG, coverage). Now normally this works out great for us since CPython is probably one of the more active projects that gets to use this increased budget, and so we typically take a chunk of the 25 concurrent builds happily and get our builds started very promptly. But at the sprints we ran up against cryptography and their crazy build needs: https://travis-ci.org/pyca/cryptography . IOW having every major Python project using Travis' free service at once hit us hard. As to whether we can get more of a budget for the sprints at PyCon US (or any other conference), I don't know. Maybe Donald could tell us more detail and/or find out if next year we can plan ahead to get a temp boost for the four days. Otherwise we're talking about making PyCA suffer year-round by having them have to get their own quota or something. On Wed, 24 May 2017 at 14:46 Guido van Rossum wrote: > I've noticed that too; the python/mypy project is also experiencing slow > builds (as is mypy/typeshed). I don't know how to contact Travis for this > though. > > On Wed, May 24, 2017 at 2:38 PM, Eric Snow > wrote: > >> tl;dr Could we temporarily bump our cap on concurrent travis builds >> during sprints? >> >> During the sprints at PyCon we've been running into a serious >> bottleneck with travis. Having an extra allowance for builds already >> is great, but during sprints even that gets swamped. I am not sure >> what projects contribute most to the problem, but I'm pretty sure it >> isn't CPython (essentially 2 builds per PR). Regardless, with the new >> workflow this bottleneck significantly impacts the higher pace that >> usually takes place at sprints. Would it make sense to see if the >> Travis folks would be willing to bump our limit temporarily during >> each sprint? >> >> -eric >> _______________________________________________ >> 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 >> > > > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > 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: From donald at stufft.io Thu May 25 17:09:24 2017 From: donald at stufft.io (Donald Stufft) Date: Thu, 25 May 2017 17:09:24 -0400 Subject: [core-workflow] travis bottleneck at sprints In-Reply-To: References:

Message-ID: <494372EA-D985-47DE-893E-433832FFB835@stufft.io> > On May 25, 2017, at 4:49 PM, Brett Cannon wrote: > > Donald is our contact with Travis, so I've explicitly added him to this email. > > To give some details: we get 25 concurrent jobs across all the various "official" Python projects on GitHub hosted under the Python, PyPA, and PyCA organizations (which is a substantial bump from what most projects get; see https://travis-ci.com/plans to get an idea of what we're getting for free). CPython itself uses 3 of those with any single PR or merge into a branch (docs, Py_DEBUG, coverage). > > Now normally this works out great for us since CPython is probably one of the more active projects that gets to use this increased budget, and so we typically take a chunk of the 25 concurrent builds happily and get our builds started very promptly. But at the sprints we ran up against cryptography and their crazy build needs: https://travis-ci.org/pyca/cryptography . IOW having every major Python project using Travis' free service at once hit us hard. > > As to whether we can get more of a budget for the sprints at PyCon US (or any other conference), I don't know. Maybe Donald could tell us more detail and/or find out if next year we can plan ahead to get a temp boost for the four days. Otherwise we're talking about making PyCA suffer year-round by having them have to get their own quota or something. > Just to be completely accurate, PyPA and PyCA had independent quotas for a long time (The default is uh, 5 I think, and both PyPA and PyCA had 10). When I reached out to Travis about getting the same for CPython, they came up with the idea of sharing a quota to allow CPython a chance to burst higher without having to add yet another dedicated queue for CPython. This generally ends up being a net positive for everyone since everyone gets a chance at a much larger burst capacity and between the three orgs we don?t generally have *too* much contention. I can reach out to Travis though about the possibility of a temporary bump during large sprints. Another option might be to reduce the human bottleneck by allowing a bot to auto merge once tests pass (although that adds more dev work of course). That way people can review and mark as approved (or even explicit to auto merge) and once tests catch up the bot handles merging it. That would allow people to generally move on once everything but waiting on tests + pressing merge button is done. ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri May 26 17:36:17 2017 From: brett at python.org (Brett Cannon) Date: Fri, 26 May 2017 21:36:17 +0000 Subject: [core-workflow] Prefix GitHub labels to group them? Message-ID: Something the Rust project does is prefix all their labels with a single letter to have alphabetical sorting keep similar labels together. For instance, using the "T - " prefix to group all type-related label like bugfix, enhancement, etc. This is all done to make it easy to find all labels for a certain thing. Do people like this idea for labels that don't naturally have a common prefix? If so would people want the single letter prefix or full word prefixes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From uehtesham90 at gmail.com Fri May 26 18:48:07 2017 From: uehtesham90 at gmail.com (Usman Ehtesham) Date: Fri, 26 May 2017 18:48:07 -0400 Subject: [core-workflow] Prefix GitHub labels to group them? In-Reply-To: References: Message-ID: <44806A42-6235-49FB-811D-B2F09B38EEB0@gmail.com> My vote is on full word prefixes (small words where and when possible) > On May 26, 2017, at 5:36 PM, Brett Cannon wrote: > > Something the Rust project does is prefix all their labels with a single letter to have alphabetical sorting keep similar labels together. For instance, using the "T - " prefix to group all type-related label like bugfix, enhancement, etc. This is all done to make it easy to find all labels for a certain thing. > > Do people like this idea for labels that don't naturally have a common prefix? If so would people want the single letter prefix or full word prefixes? > _______________________________________________ > 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 From uehtesham90 at gmail.com Fri May 26 18:49:55 2017 From: uehtesham90 at gmail.com (Usman Ehtesham) Date: Fri, 26 May 2017 18:49:55 -0400 Subject: [core-workflow] Prefix GitHub labels to group them? In-Reply-To: References: Message-ID: <84850EBD-AA08-48A2-9222-5C8022E2AD31@gmail.com> Maybe the prefixes can be similar to how Falcon uses types in its commit messages: https://github.com/falconry/falcon/blob/master/CONTRIBUTING.md#type > On May 26, 2017, at 5:36 PM, Brett Cannon wrote: > > Something the Rust project does is prefix all their labels with a single letter to have alphabetical sorting keep similar labels together. For instance, using the "T - " prefix to group all type-related label like bugfix, enhancement, etc. This is all done to make it easy to find all labels for a certain thing. > > Do people like this idea for labels that don't naturally have a common prefix? If so would people want the single letter prefix or full word prefixes? > _______________________________________________ > 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: From jayvdb at gmail.com Fri May 26 20:34:20 2017 From: jayvdb at gmail.com (jayvdb at gmail.com) Date: Sat, 27 May 2017 00:34:20 +0000 Subject: [core-workflow] Prefix GitHub labels to group them? In-Reply-To: <44806A42-6235-49FB-811D-B2F09B38EEB0@gmail.com> References: <44806A42-6235-49FB-811D-B2F09B38EEB0@gmail.com> Message-ID: coala uses full word prefixes for type, size, importance, and difficulty. https://github.com/coala/coala/labels And has a bot that auto labels when the suffixes are used in the issue/PR message. On Sat, 27 May 2017 05:48 Usman Ehtesham wrote: > My vote is on full word prefixes (small words where and when possible) > > > On May 26, 2017, at 5:36 PM, Brett Cannon wrote: > > > > Something the Rust project does is prefix all their labels with a single > letter to have alphabetical sorting keep similar labels together. For > instance, using the "T - " prefix to group all type-related label like > bugfix, enhancement, etc. This is all done to make it easy to find all > labels for a certain thing. > > > > Do people like this idea for labels that don't naturally have a common > prefix? If so would people want the single letter prefix or full word > prefixes? > > _______________________________________________ > > 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 > > _______________________________________________ > 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: From gvanrossum at gmail.com Fri May 26 20:52:15 2017 From: gvanrossum at gmail.com (Guido van Rossum) Date: Fri, 26 May 2017 17:52:15 -0700 Subject: [core-workflow] Prefix GitHub labels to group them? In-Reply-To: References: <44806A42-6235-49FB-811D-B2F09B38EEB0@gmail.com> Message-ID: We have such a convention in mypy too. GitHub.com/python/mypy/labels. On May 26, 2017 5:34 PM, wrote: coala uses full word prefixes for type, size, importance, and difficulty. https://github.com/coala/coala/labels And has a bot that auto labels when the suffixes are used in the issue/PR message. On Sat, 27 May 2017 05:48 Usman Ehtesham wrote: > My vote is on full word prefixes (small words where and when possible) > > > On May 26, 2017, at 5:36 PM, Brett Cannon wrote: > > > > Something the Rust project does is prefix all their labels with a single > letter to have alphabetical sorting keep similar labels together. For > instance, using the "T - " prefix to group all type-related label like > bugfix, enhancement, etc. This is all done to make it easy to find all > labels for a certain thing. > > > > Do people like this idea for labels that don't naturally have a common > prefix? If so would people want the single letter prefix or full word > prefixes? > > _______________________________________________ > > 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 > > _______________________________________________ > 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 > _______________________________________________ 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: From brett at python.org Sat May 27 14:45:21 2017 From: brett at python.org (Brett Cannon) Date: Sat, 27 May 2017 18:45:21 +0000 Subject: [core-workflow] Prefix GitHub labels to group them? In-Reply-To: References: <44806A42-6235-49FB-811D-B2F09B38EEB0@gmail.com>

Message-ID: I have gone ahead and added appropriate prefixes. Thanks for the feedback everyone! On Fri, 26 May 2017 at 17:52 Guido van Rossum wrote: > We have such a convention in mypy too. GitHub.com/python/mypy/labels. > > > On May 26, 2017 5:34 PM, wrote: > > coala uses full word prefixes for type, size, importance, and difficulty. > > https://github.com/coala/coala/labels > > And has a bot that auto labels when the suffixes are used in the issue/PR > message. > > > On Sat, 27 May 2017 05:48 Usman Ehtesham wrote: > >> My vote is on full word prefixes (small words where and when possible) >> >> > On May 26, 2017, at 5:36 PM, Brett Cannon wrote: >> > >> > Something the Rust project does is prefix all their labels with a >> single letter to have alphabetical sorting keep similar labels together. >> For instance, using the "T - " prefix to group all type-related label like >> bugfix, enhancement, etc. This is all done to make it easy to find all >> labels for a certain thing. >> > >> > Do people like this idea for labels that don't naturally have a common >> prefix? If so would people want the single letter prefix or full word >> prefixes? >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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: