[python-committers] Turning off AppVeyor as required
Victor noticed that AppVeyor stopped building about 19 hours ago, leading to it blocking all open PRs. I have gone ahead and switched off requiring AppVeyor for now, so please pay attention to at least the Windows VSTS status check to make sure you're not breaking Windows by accident. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
Hum. For backports, should we stop to approve PRs in advance? miss-islington currently ignores VSTS status and so may merge a backport even if VSTS Windows fails. Victor 2018-06-04 17:02 GMT+02:00 Brett Cannon : > Victor noticed that AppVeyor stopped building about 19 hours ago, leading to > it blocking all open PRs. I have gone ahead and switched off requiring > AppVeyor for now, so please pay attention to at least the Windows VSTS > status check to make sure you're not breaking Windows by accident. > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
I'm currently not in the mood to argue about VSTS' stability so I don't feel comfortable flipping that on as a requirement quite yet. On Mon, 4 Jun 2018 at 08:33 Victor Stinner wrote: > Hum. For backports, should we stop to approve PRs in advance? > miss-islington currently ignores VSTS status and so may merge a > backport even if VSTS Windows fails. > > Victor > > 2018-06-04 17:02 GMT+02:00 Brett Cannon : > > Victor noticed that AppVeyor stopped building about 19 hours ago, > leading to > > it blocking all open PRs. I have gone ahead and switched off requiring > > AppVeyor for now, so please pay attention to at least the Windows VSTS > > status check to make sure you're not breaking Windows by accident. > > > > ___ > > python-committers mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/python-committers > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
2018-06-04 18:18 GMT+02:00 Brett Cannon : > I'm currently not in the mood to argue about VSTS' stability so I don't feel > comfortable flipping that on as a requirement quite yet. I don't suggest to make it mandatory right now. I will try to keep on eye on VSTS ;-) Victor ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
> > miss-islington currently ignores VSTS status No it does not yet ignore VSTS status. If VSTS status failed, it will not automerge. Mariatta ᐧ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
On 04Jun2018 0932, Victor Stinner wrote: 2018-06-04 18:18 GMT+02:00 Brett Cannon : I'm currently not in the mood to argue about VSTS' stability so I don't feel comfortable flipping that on as a requirement quite yet. I don't suggest to make it mandatory right now. I will try to keep on eye on VSTS ;-) FWIW I had a quick look through the history of Windows commit builds on VSTS. There last three failures were: * test_subprocess getting wedged and the build timed out (surprisingly gracefully though, it sent a Ctrl+C to the app so we still got all the output) * Tcl/tk and/or OpenSSL build got stuck (this was on 3.6 - we don't build these every time as of 3.7) * test_asyncio issues Since the last of those issue, there have been 50-ish successful builds. (Note that I looked at commit builds, not PR builds, so I wouldn't have to wade through every single PR to see if it was a genuine bug.) You can review the history here: Windows commits: https://python.visualstudio.com/cpython/_build/index?definitionId=4&_a=history&path=%5C Windows PRs: https://python.visualstudio.com/cpython/_build/index?definitionId=9&_a=history&path=%5C macOS commits: https://python.visualstudio.com/cpython/_build/index?definitionId=5&_a=history&path=%5C macOS PRs: https://python.visualstudio.com/cpython/_build/index?definitionId=8&_a=history&path=%5C Linux commits: https://python.visualstudio.com/cpython/_build/index?definitionId=6&_a=history&path=%5C Linux PRs: https://python.visualstudio.com/cpython/_build/index?definitionId=7&_a=history&path=%5C Linux with code coverage: https://python.visualstudio.com/cpython/_build/index?definitionId=13&_a=history&path=%5C (both commits and PRs right now, still undecided how to best make use of this run, as we don't seem to report coverage stats anywhere?) Cheers, Steve ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Wrongly stopping merges discourages merging.
On Sun, 3 Jun 2018 at 20:30 Ned Deily wrote: > On Jun 3, 2018, at 22:30, Steve Dower 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. -Brett > > -- > Ned Deily > [email protected] -- [] > > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
By the way, Python 2.7 doesn't have AppVeyor nor VSTS? Is there a plan to add VSTS to Python 2.7? Victor 2018-06-04 18:46 GMT+02:00 Steve Dower : > On 04Jun2018 0932, Victor Stinner wrote: >> >> 2018-06-04 18:18 GMT+02:00 Brett Cannon : >>> >>> I'm currently not in the mood to argue about VSTS' stability so I don't >>> feel >>> comfortable flipping that on as a requirement quite yet. >> >> >> I don't suggest to make it mandatory right now. >> >> I will try to keep on eye on VSTS ;-) > > > FWIW I had a quick look through the history of Windows commit builds on > VSTS. There last three failures were: > * test_subprocess getting wedged and the build timed out (surprisingly > gracefully though, it sent a Ctrl+C to the app so we still got all the > output) > * Tcl/tk and/or OpenSSL build got stuck (this was on 3.6 - we don't build > these every time as of 3.7) > * test_asyncio issues > > Since the last of those issue, there have been 50-ish successful builds. > (Note that I looked at commit builds, not PR builds, so I wouldn't have to > wade through every single PR to see if it was a genuine bug.) > > You can review the history here: > > Windows commits: > https://python.visualstudio.com/cpython/_build/index?definitionId=4&_a=history&path=%5C > Windows PRs: > https://python.visualstudio.com/cpython/_build/index?definitionId=9&_a=history&path=%5C > macOS commits: > https://python.visualstudio.com/cpython/_build/index?definitionId=5&_a=history&path=%5C > macOS PRs: > https://python.visualstudio.com/cpython/_build/index?definitionId=8&_a=history&path=%5C > Linux commits: > https://python.visualstudio.com/cpython/_build/index?definitionId=6&_a=history&path=%5C > Linux PRs: > https://python.visualstudio.com/cpython/_build/index?definitionId=7&_a=history&path=%5C > Linux with code coverage: > https://python.visualstudio.com/cpython/_build/index?definitionId=13&_a=history&path=%5C > (both commits and PRs right now, still undecided how to best make use of > this run, as we don't seem to report coverage stats anywhere?) > > Cheers, > Steve > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
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. Top-posted from my Windows 10 phone From: Victor Stinner Sent: Monday, June 4, 2018 10:07 To: Steve Dower Cc: python-committers Subject: Re: [python-committers] Turning off AppVeyor as required By the way, Python 2.7 doesn't have AppVeyor nor VSTS? Is there a plan to add VSTS to Python 2.7? Victor 2018-06-04 18:46 GMT+02:00 Steve Dower : > On 04Jun2018 0932, Victor Stinner wrote: >> >> 2018-06-04 18:18 GMT+02:00 Brett Cannon : >>> >>> I'm currently not in the mood to argue about VSTS' stability so I don't >>> feel >>> comfortable flipping that on as a requirement quite yet. >> >> >> I don't suggest to make it mandatory right now. >> >> I will try to keep on eye on VSTS ;-) > > > FWIW I had a quick look through the history of Windows commit builds on > VSTS. There last three failures were: > * test_subprocess getting wedged and the build timed out (surprisingly > gracefully though, it sent a Ctrl+C to the app so we still got all the > output) > * Tcl/tk and/or OpenSSL build got stuck (this was on 3.6 - we don't build > these every time as of 3.7) > * test_asyncio issues > > Since the last of those issue, there have been 50-ish successful builds. > (Note that I looked at commit builds, not PR builds, so I wouldn't have to > wade through every single PR to see if it was a genuine bug.) > > You can review the history here: > > Windows commits: > https://python.visualstudio.com/cpython/_build/index?definitionId=4&_a=history&path=%5C > Windows PRs: > https://python.visualstudio.com/cpython/_build/index?definitionId=9&_a=history&path=%5C > macOS commits: > https://python.visualstudio.com/cpython/_build/index?definitionId=5&_a=history&path=%5C > macOS PRs: > https://python.visualstudio.com/cpython/_build/index?definitionId=8&_a=history&path=%5C > Linux commits: > https://python.visualstudio.com/cpython/_build/index?definitionId=6&_a=history&path=%5C > Linux PRs: > https://python.visualstudio.com/cpython/_build/index?definitionId=7&_a=history&path=%5C > Linux with code coverage: > https://python.visualstudio.com/cpython/_build/index?definitionId=13&_a=history&path=%5C > (both commits and PRs right now, still undecided how to best make use of > this run, as we don't seem to report coverage stats anywhere?) > > Cheers, > Steve > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Wrongly stopping merges discourages merging.
On Sun, 3 Jun 2018 at 13:23 Terry Reedy wrote: > When we used hg, core dev committers could actually commit to the > repository when they judged it appropriate. When we moved to github, > Brett, with whoever's approval, 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. > decided that we should no longer be > trusted to make commits without approval of a couple of mindless robots. > However, the premise that the robots should be trusted is false. So I > again request that there be a manual override for when the robots are > obviously giving false failures. > 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). > > Exhibit 1. For at least a couple of weeksin may, faults in the asyncio > test (and another) caused the asyncio test to randomly fail about half > the time. With one retest, each CI bot failed about 1/4 the time. At > least one bot of the two bots failed about 1/2 the time. The AppVeyor > queue ballooned. > > One could decrease the frustration and time to success (but only partly) > by only re-starting the bot that failed. Doing so for Travis is > fairly easy. Doing so with AppVeyor is obscure and error prone. > > I twice requested that the randomly failing tests be disabled. Victor > said he wanted to keep monitoring what they did. I think he overly > discounted the pain and frustration of having good merges blocked. I > think either 1) bad tests should be disabled, or 2. the CI code should > be able to ignore failures by bad tests, or 3. responsible core devs > should be able to. > > Exhibit 2. AppVeyor is badly broken. > > This morning Cheryl Sabella submitted a nice patch fixing an annoying > behavior of IDLE's editor/shell/output windows. The CI tests passed, > the patch worked great, it only needed expansion of the placeholder > blurb. I was really excited. > > With some trepidation, I made the edit. Unfortunately, both CI bots > rerun the code tests even when the code is unchanged. Blurb edits > should be treated as doc-only changes, with only the blurb rechecked. > > My trepidation turned out to be well-founded. My excitement is gone. > After an error, AppVeyor just quit without reporting any failure cause. > https://ci.appveyor.com/project/python/cpython/build/3.8build16869 > > Since then, there have been 2 successes and 7 similar unexplained failures. > https://ci.appveyor.com/project/python/cpython/history > > https://ci.appveyor.com/project/python/cpython/build/3.6build16871/job/c2q80njh9clnfgjt > https://ci.appveyor.com/project/python/cpython/build/3.8build16872 > https://ci.appveyor.com/project/python/cpython/build/3.7build16873 > https://ci.appveyor.com/project/python/cpython/build/3.8build16874 > > https://ci.appveyor.com/project/python/cpython/build/3.6build16876/job/t9nyt59wkwcn68nk > https://ci.appveyor.com/project/python/cpython/build/3.8build16877 > https://ci.appveyor.com/project/python/cpython/build/3.8build16878 > > The last is my restart. The time wasted by this broken blockbot is time > not spent doing something useful. I would really like to have this > patch in the .rc in a week -- along with a few others that should follow. > > Guido once asked what is off-putting about being a core developer. This > is one thing. > 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). ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Wrongly stopping merges discourages merging.
I’d also add that it is generally a good thing that people with power and a voice (e.g. the core devs) are having a similar experience that an external contributor would. This is our best line of defense against the external contributor experience degrading to a bad place. By having core devs share a similar experience, we can get feedback like the one about AppVeyor and try to improve things for everyone, instead of simply giving core devs a way to opt out of the pain. Sent from my iPhone > On Jun 4, 2018, at 1:54 PM, Brett Cannon wrote: > > 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). ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Wrongly stopping merges discourages merging.
+1. For example for mypy I use the "triangular" git setup even though as a mypy core dev I could simply push my branch to the main repo. On Mon, Jun 4, 2018 at 11:49 AM, Donald Stufft wrote: > I’d also add that it is generally a good thing that people with power and > a voice (e.g. the core devs) are having a similar experience that an > external contributor would. This is our best line of defense against the > external contributor experience degrading to a bad place. By having core > devs share a similar experience, we can get feedback like the one about > AppVeyor and try to improve things for everyone, instead of simply giving > core devs a way to opt out of the pain. > > Sent from my iPhone > > > On Jun 4, 2018, at 1:54 PM, Brett Cannon wrote: > > > > 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). > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Turning off AppVeyor as required
I have very good news from AppVeyor: * AppVeyor runs again jobs on pull requests: it's back! * Issue with quotas: it was a disk issue, it was on their side and it's now fixed. * AppVeyor donate us additional parallel job to the python account! Moreover: * They proposed us to extend the timeout to 90 minuts. Hopefully, a full build (download + compile + run tests) takes usually less than 15 min, so it's fine. * They explained me how to disable AppVeyor on branches to only run tests on pull requests. "Do not build feature branches with open Pull Requests in UI (skip_branch_with_pr: true if you use YAML)." seems the safest option. Another option is: "disable Pushes event in GitHub Webhook settings" but I don't undestand if it only impacts AppVeyor or all our hooks. Thank you very much AppVeyor! See my support issue for the details: http://help.appveyor.com/discussions/problems/14532-cpython-exceeded-allowed-resource-quotas-what-are-these-quotas-can-them-be-increased Victor 2018-06-04 17:02 GMT+02:00 Brett Cannon : > Victor noticed that AppVeyor stopped building about 19 hours ago, leading to > it blocking all open PRs. I have gone ahead and switched off requiring > AppVeyor for now, so please pay attention to at least the Windows VSTS > status check to make sure you're not breaking Windows by accident. > > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] number of active core devs [was: Comments on moving issues to GitHub]
On Sun, Jun 03, 2018 at 12:44:55PM -0700, Brett Cannon wrote:
> I will admit that I think we lost some core devs who had zero exposure to
> GitHub prior to switching and never found the motivation to ramp up on the
> new workflow.
*raises hand*
I'm one of them. Not that I was a prolific core dev, but I did have
commit priviliges.
I'm not a full-time programmer, and the discipline of using VCS does not
come naturally to me. Without doing it daily, or even weekly, it always
feels like friction rather than something helpful. (Intellectually, I
understand the benefits, but emotionally it is another story.)
It took me a long while to get used to hg, and just when I had, we
changed to git and everything I thought I knew was wrong :-)
Add to that some unrelated changes in my personal life, and my
motivation to learn the new workflow dropped to not just zero but became
negative. But I've keep up with the community, and I feel my motivation
gradually increasing. It's now above zero and just waiting on me finding
time :-)
(Given today's news about Microsoft and Github, I'll probably just learn
the Github workflow in time for us to move to something different again
*wink*)
Long ago, when we first started discussing this move, I asked if we had
an objective measure of what would count as "success" in the move. I'm
not sure I was ever answered, but given the motives expressed at the
time ("make it easier to recruit core devs" I think was one of them) I
don't think the move has been a complete success.
That's not to call it a failure: it clearly hasn't been that, and to
those who know git and like github, it has clearly been a win for them.
But I think it is important to acknowledge which of our goals were met
and which were not.
--
Steve
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
