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 <gu...@python.org> 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 <ericsnowcurren...@gmail.com> > 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@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@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@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
