[python-committers] Wrongly stopping merges discourages merging.
brett at python.org
Mon Jun 4 12:54:12 EDT 2018
On Sun, 3 Jun 2018 at 20:30 Ned Deily <nad at python.org> wrote:
> 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?
I'll start a discussion over on core-workflow.
> Ned Deily
> nad at python.org -- 
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the python-committers