<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 3 Jun 2018 at 13:23 Terry Reedy <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When we used hg, core dev committers could actually commit to the <br>
repository when they judged it appropriate. When we moved to github, <br>
Brett, with whoever's approval,</blockquote><div><br></div><div>Since this seems very much directed at me, I should mention any authority I have has either come from Guido and/or the PEP process. If people are unhappy with my work then please feel free to bring it up and we can discuss having my privileges taken away.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> decided that we should no longer be <br>
trusted to make commits without approval of a couple of mindless robots. <br>
However, the premise that the robots should be trusted is false. So I <br>
again request that there be a manual override for when the robots are <br>
obviously giving false failures.<br></blockquote><div><br></div><div>Please realize that every time we have switched off CI, we have ended up with a broken branch, so it's a trade-off between these occasional hiccups or occasionally broken branches (and as Victor has pointed out, we are not always good as a group about making sure we notice when stuff breaks). Also note that because we now have branches that are almost always stable we have users who actually run from a checkout directly instead of waiting for a release (which also benefits us by helping to surface bugs earlier than e.g. an RC).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Exhibit 1. For at least a couple of weeksin may, faults in the asyncio <br>
test (and another) caused the asyncio test to randomly fail about half <br>
the time. With one retest, each CI bot failed about 1/4 the time. At <br>
least one bot of the two bots failed about 1/2 the time. The AppVeyor <br>
queue ballooned.<br>
<br>
One could decrease the frustration and time to success (but only partly) <br>
by only re-starting the bot that failed. Doing so for Travis is <br>
fairly easy. Doing so with AppVeyor is obscure and error prone.<br>
<br>
I twice requested that the randomly failing tests be disabled. Victor <br>
said he wanted to keep monitoring what they did. I think he overly <br>
discounted the pain and frustration of having good merges blocked. I <br>
think either 1) bad tests should be disabled, or 2. the CI code should <br>
be able to ignore failures by bad tests, or 3. responsible core devs <br>
should be able to.<br>
<br>
Exhibit 2. AppVeyor is badly broken.<br>
<br>
This morning Cheryl Sabella submitted a nice patch fixing an annoying <br>
behavior of IDLE's editor/shell/output windows. The CI tests passed, <br>
the patch worked great, it only needed expansion of the placeholder <br>
blurb. I was really excited.<br>
<br>
With some trepidation, I made the edit. Unfortunately, both CI bots <br>
rerun the code tests even when the code is unchanged. Blurb edits <br>
should be treated as doc-only changes, with only the blurb rechecked.<br>
<br>
My trepidation turned out to be well-founded. My excitement is gone. <br>
After an error, AppVeyor just quit without reporting any failure cause.<br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.8build16869" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.8build16869</a><br>
<br>
Since then, there have been 2 successes and 7 similar unexplained failures.<br>
<a href="https://ci.appveyor.com/project/python/cpython/history" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/history</a><br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.6build16871/job/c2q80njh9clnfgjt" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.6build16871/job/c2q80njh9clnfgjt</a><br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.8build16872" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.8build16872</a><br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.7build16873" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.7build16873</a><br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.8build16874" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.8build16874</a><br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.6build16876/job/t9nyt59wkwcn68nk" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.6build16876/job/t9nyt59wkwcn68nk</a><br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.8build16877" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.8build16877</a><br>
<a href="https://ci.appveyor.com/project/python/cpython/build/3.8build16878" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/python/cpython/build/3.8build16878</a><br>
<br>
The last is my restart. The time wasted by this broken blockbot is time <br>
not spent doing something useful. I would really like to have this <br>
patch in the .rc in a week -- along with a few others that should follow.<br>
<br>
Guido once asked what is off-putting about being a core developer. This <br>
is one thing.<br></blockquote><div><br></div><div>So both examples seem very focused on AppVeyor and the first one somewhat at CI overall. As stated in another email, I have turned off AppVeyor being required so 1.5 of these issues have been dealt with (and based on a PR I looked it the requirement retroactively went away for all open PRs).<br></div></div></div>