On Mon, Oct 19, 2020 at 11:22 AM Ned Deily <n...@python.org> wrote: > On Oct 19, 2020, at 13:59, Brett Cannon <br...@python.org> wrote: > > On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman <et...@stoneleaf.us> wrote: > >> On 10/18/20 1:18 PM, Ned Deily wrote: > >> > On Oct 18, 2020, at 15:45, Carol Willing <willi...@gmail.com> wrote: > >> >> We've largely moved away from Travis for Jupyter testing in favor of > Azure pipelines and CircleCI as Travis was becoming increasingly slow and > timing out. > >> > > >> > Along those lines, if we are basically going to ignore the Travis CI > results, perhaps we should consider being "good citizens" and stop running > them all together. Each PR change triggers multiple builds to run under > Travis and all that extra and useless work contributes to the load on > Travis and no doubt is not good for overall Travis responsiveness. > >> > >> If we have something else set up to takes its place that's fine; > otherwise, let's leave it up with the understanding > >> that we have to check it manually for success or failure -- that's > still valuable information. > > Unfortunately, the "valuable information" lately has been whether Travis > is even working. 😉 > > Yes, and I still think it's unfair of us to use so much of Travis's > resources - resources that other projects could use - when we are almost > entirely ignoring the results. On the master branch, each time a PR is > merged or requires a CI run, we currently start up to 5 separate Travis > jobs (some short-circuited but still jobs). The main job. which rebuilds > python and runs the test suite, can run for 15+ minutes. And then > backports run some of the jobs as well. >
Yep, if Travis has limited their free resources then we are wasting them. And without knowing where Travis gets their electricity there's even a potentially (very slight) ecological cost from us wasting the runs. I am with Ned about trying on to be wasteful here *just* *in case* Travs happens to find something in a CI run. > > Let's just disable Travis on all branches for now until there is reason to > believe the problems we've seen are fixed. > +1 from me. > > -- > Ned Deily > n...@python.org -- [] > _______________________________________________ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/AYLXEBIFHWCODJSIRS3W2C2HSQKHYRHM/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ >
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/IRHJ23U4AWODZFNWK3PCB2PDIRXAEQSB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
