On Fri, May 18, 2018 at 8:38 AM Brett Cannon <brett@python.org> wrote:

On Fri, 18 May 2018 at 01:09 Gregory P. Smith <greg@krypto.org> wrote:
> Hi all,
> I had a long discussion with Steve at PyCon about VSTS. The benefits seem promising.
> 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. :(

No one has turned anything off or changed what is required. Looking at the two latest PRs they both have Travis and AppVeyor running (https://github.com/python/cpython/pull/6971 is for master, https://github.com/python/cpython/pull/6972 is for 2.7). Did you happen to not scroll down the status check section in your browser? GitHub puts the required checks at the bottom (which has also not changed).

While we're in the middle of a release cycle!

Yep, and nothing has changed except we have added more CI; nothing else has changed.

> 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 requirement
> 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.

No, Travis and AppVeyor ran and they both say the PR passed. The issue is only that the Linux build on VSTS failed and miss-islington doesn't distinguish between required status checks and any status check. It can still be merged by clicking the "Squash and merge" button.

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 it.

I'm going to choose to assume the tone used in this email is due to a misunderstanding of not noticing that Travis and AppVeyor are in fact still running and are required along with an oversight -- that I can take blame for if that's necessary -- that miss-islington doesn't distinguish between required and optional status checks when deciding whether to automatically merge. We can temporarily flip off VSTS if automatic merging is viewed as critical right now until after the RC, but otherwise all that has happened is we have introduced more CI which isn't as stable as Travis and AppVeyor yet due to working out testing kinks which did not come up when Steve was testing this on his fork of CPython (which we had to do for both Travis and AppVeyor as well).

But in the future, please give us the benefit of the doubt. I'm sitting in MSP trying to deal with this, stressed up the wazoo from worrying that somehow someone had changed something without speaking with me or a release manager, all while about to get on a plane after frankly being yelled at by a friend. :(

Sorry. Big misunderstanding on my part. I made wrong assumptions due in part to poor UI design. :(

It appears to be a combination of Github's UI failure interacting with the added Checkers.  There was no longer a green merge button and the list displayed by github hides the runs i care about below a completely arbitrary invisible "fold" which led me to believe they were no longer being run.

I'm happy to see that the known-good CI is still being run!

But Github is no longer showing it without additional secret effort to find as it is hidden at the bottom of an invisible scrolling region.

I could also blame the last decades dumb insistence on removing scrollbars from UIs for this, but it is up to github to work around the current decade bad ui paradigms.  The Github UI says "show all" but does not in fact "show all".  It "shows five" and doesn't tell you that it can scroll.