On Mon, Oct 19, 2020 at 11:22 AM Ned Deily <nad@python.org> wrote:
On Oct 19, 2020, at 13:59, Brett Cannon <brett@python.org> wrote:
> On Sun, Oct 18, 2020 at 2:21 PM Ethan Furman <ethan@stoneleaf.us> wrote:
>> On 10/18/20 1:18 PM, Ned Deily wrote:
>> > On Oct 18, 2020, at 15:45, Carol Willing <willingc@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
  nad@python.org -- []
_______________________________________________
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-leave@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/