> Hi all,
> I had a long discussion with Steve at PyCon about VSTS. The benefits seem
> Perhaps a reasonable step forward is to run Travis, AppVeyor, and VSTS as
> required for 3
> months or 6 months. This would give everyone a view into using VSTS.
But that isn't what happened.
Someone turned off our Travis and AppVeyor CI systems and made the unreliable
VSTS system a PR merge blocker. :(
While we're in the middle of a release cycle!
> After the initial period, we could then revisit what makes sense in the
> longer term. Which
> could be to continue using and requiring all; use all but perhaps relax the
> for passing; or to choose one preferred combination of tools.
That would be the only sane way to do this.
instead, we have:
both of which are entirely useless, providing zero information about what went
wrong. and are clearly infrastructure failures. The UI has ZERO LOGS, and
doesn't even link back to the github thing that triggered it.
for reference, those runs came from these issues:
Those PRs can't be merged into to 3.6 or 3.7 because of VSTS and whomever made
the choice to hold the CPython repo hostage.
I am not impressed.
Bring back Travis and AppVeyor. Microsoft's currently alpha-quality toy must
not be a merge blocker until after it has proven itself stable for at least a
month. Even after that, if it continues to have a UI that doesn't put the logs
up front and center when opening a failure, I will never want to open a link to
core-workflow mailing list -- email@example.com
To unsubscribe send an email to core-workflow-le...@python.org
This list is governed by the PSF Code of Conduct: