IHMO this issue is a blocker to make VSTS mandatory:
VSTS Windows-PR failed with "The request was failed due to an internal
service error. Please try again."
It would prevent to not be blocked by an internal VSTS error :-(
While I agree it should be looked into (which I know it is as I'm cc'ed on the internal emails), I don't think making it a blocker is quite fair. If blocking making VSTS required for a couple of failed builds due to an internal error that could be kicked off by closing and re-opening a PR then I don't know if it's reasonable to require AppVeyor again when they were down for all PRs for 20 hours.
My point is this is all software which we know isn't perfect and as long as there is a way to kick off a wedged/failed build again I don't think it's a hard blocker.
2018-06-05 20:07 GMT+02:00 Brett Cannon <firstname.lastname@example.org>:
> On Tue, 5 Jun 2018 at 03:52 Victor Stinner <email@example.com> wrote:
>> Steve has no plan to support VSTS on Python 2.7:
>> "Correct, and I wasn't planning on it. The default VSTS machines don’t
>> have the right compiler, and I’m not about to start managing VMs for
>> 2.7 at this stage."
>> So I would suggest to keep AppVeyor for Python 2.7, at least for the
>> short term, and maybe make it mandatory again since it works again we
>> doubled our capacity (1 job => 2 jobs in parallel)!
>> The workflow velocity is less impact for Python 2.7 which gets less
>> changes than 3.x & master branches.
> Yep, that's what I was thinking of doing on Friday.
>> 2018-06-04 20:34 GMT+02:00 Brett Cannon <firstname.lastname@example.org>:
>> > We had to turn off AppVeyor as a requirement today due to it not running
>> > any
>> > builds for the last 20 hours. Ned Deily suggested that since VSTS on at
>> > least Windows has stabilized that maybe we should switch off AppVeyor
>> > off
>> > entirely and make the Windows VSTS builder required.
>> > Since
>> > https://python.visualstudio.com/cpython/_build/index?context=mine&path=%5C&definitionId=4&_a=history
>> > shows the builder has been stable I would like to make this required for
>> > master today/tomorrow and then flip it on for the other 3.x branches on
>> > Friday if we don't see any instability.
>> > Any objections/opinions about doing this?
>> > _______________________________________________
>> > core-workflow mailing list -- email@example.com
>> > To unsubscribe send an email to firstname.lastname@example.org
>> > https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
>> > This list is governed by the PSF Code of Conduct:
>> > https://www.python.org/psf/codeofconduct