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

core-workflow mailing list
This list is governed by the PSF Code of Conduct:

--Guido van Rossum (
core-workflow mailing list
This list is governed by the PSF Code of Conduct: