<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 19 Sep 2017 at 15:04 Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sep 19, 2017, at 15:32, Victor Stinner <<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@gmail.com</a>> wrote:<br>
><br>
> The macOS job has been removed from Travis CI at the beginnig of the<br>
> CPython sprint two weeks ago. Since the macOS build was removed, I'm<br>
> less annoyed by Travis CI: it seems more stable.<br>
><br>
> Are you ok to not add again the macOS job to Travis CI?<br>
><br>
> Again, my rationale is that we already have 3 macOS buildbots and I'm<br>
> looking closely at all buildbot failures. I try to keep track of *all*<br>
> failures, even random failure. A recent macOS example:<br>
> <a href="https://bugs.python.org/issue31510" rel="noreferrer" target="_blank">https://bugs.python.org/issue31510</a><br>
><br>
> Sadly, remaining random failures are the most rare and most difficult<br>
> to reproduce. (I fixed a lot of them last months.)<br>
<br>
If the macOS tests aren’t stable, then yes, removing them is better than frustrating developers who can’t reproduce CI failures, even on the CI machines let alone their own development boxes.<br>
<br>
I forget though, was it a problem with macOS CI stability or general throughput?  I thought they just couldn’t keep up with the workload, in which case it seems like we should be able to throw more resources at it, right?<br></blockquote><div><br></div><div>If it is a Travis issue then there are no more resources to throw at it from a Travis perspective: what they are already providing us is rather large and paying out of pocket is rather costly. The only other option is to find another CI provider who has macOS support and use them just for that platform.<br></div></div></div>