Mailman 3 May 2017 - core-workflow

Prefix GitHub labels to group them?
by Brett Cannon 27 May '17

27 May '17

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?

4 5

travis bottleneck at sprints
by Eric Snow 26 May '17

26 May '17

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

4 3

Workflow for applying b.p.o patches to GitHub
by Mariatta Wijaya 15 May '17

15 May '17

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

2 1

Are the "cherry-pick for *" labels on GitHub useful?
by Brett Cannon 13 May '17

13 May '17

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?

3 6

Re: [core-workflow] Where to host documentation? (was: Voting on possible subdomains for the devguide)
by Eric Holscher 10 May '17

10 May '17

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

2 1