[python-committers] Wrongly stopping merges discourages merging.

[Ned Deily]

On Jun 3, 2018, at 22:30, Steve Dower <steve.dower at python.org> wrote:
> We probably have enough data on the VSTS builds by now to see whether they are comparable/faster than AppVeyor. Obviously the idea of doing that work was to be able to migrate builds if it made sense, and if we decide not to then they get ripped out (non-binding PR checks are confusing IMHO, particularly when they duplicate required checks).
>  
> I have no idea whether that discussion is still ongoing on core-workflow, but if it seems better then maybe it’s time? Anyone can view the VSTS build history starting from https://python.visualstudio.com/cpython/_build and browsing into the build definition of interest.

My gut feel from observing the progress of PRs over the past couple of weeks is that the VSTS CI builds are faster and much less problematic than the AppVeyor builds have been.  That said, one significant Windows test bottleneck was identified last week (largefile tests in test_mmap) on some buildbots and was disabled.  We've now also disabled it on AppVeyor, once AppVeyor starts running our tests again, and I've suggested it be disabled on the VSTS Windows CI runs as well.  That, along with a number of other test fixes made over the past week, may help eliminate with AppVeyor.  But, at this point, I think we should seriously consider dropping mandatory AppVeyor CI runs in favor of the VSTS ones.

Brett, do you concur?  And, if so, can you make it happen?

--
  Ned Deily
  nad at python.org -- []