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
tl;dr Could we temporarily bump our cap on concurrent travis builds
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
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.
1. Can anyone prepare the GitHub PR based on the patch? or only core
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.
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?
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.
Maker of the internet residing in Portland, Oregon