Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!
Le 14 avr. 2016 11:16 AM, "Serhiy Storchaka" <storchaka@gmail.com> a écrit :
A desirable but nonexistent feature is to write emails to authors of commits that broke buildbots. How hard to implement this?
Yeah I also had this idea since many years but buildbots were quite unstable. Maybe we should be more strict to consider a buildbot as stable? I propose to experiment sending notifications of failure to the authors of changes *and* to a new mailing list. I would subscribe to such list. An even safer starting point would be to only start with the mailing list. FYI I'm connected to the #python-dev IRC channel which already contain these notifications. But I agree that mails are better.
What are you think about backporting recent regrtest to 2.7? Most needed features to me are the -m and -G options.
Regrtest changed a lot in python 3.6 (new test.libregrtest library). I suggest to start from python 3.5. For -m: if it doesn't need to modify the unittest module, I agree. I don't know -G option.
Would be nice to add a feature for running every test in separate subprocess. This will isolate the effect of failed tests.
See my email :-) I proposed to modify -j1 to run tests in subrpocesses. I even mentionned my issue. I suggest to use -jN on all buildbot, at least -j1. Maybe -j2 is even better since many tests are waiting on IO or simple sleep. Victor
On Thu, 14 Apr 2016 at 03:26 Victor Stinner <victor.stinner@gmail.com> wrote:
Le 14 avr. 2016 11:16 AM, "Serhiy Storchaka" <storchaka@gmail.com> a écrit :
A desirable but nonexistent feature is to write emails to authors of commits that broke buildbots. How hard to implement this?
Yeah I also had this idea since many years but buildbots were quite unstable. Maybe we should be more strict to consider a buildbot as stable?
Depending on how fancy we get with our infrastructure after we move to GitHub, we could theoretically end up with a PR-merging bot that can detect which commit broke things and report on the PR that did it (we well as report anywhere else we wanted to).
I propose to experiment sending notifications of failure to the authors of changes *and* to a new mailing list. I would subscribe to such list. An even safer starting point would be to only start with the mailing list.
FYI I'm connected to the #python-dev IRC channel which already contain these notifications. But I agree that mails are better.
Yeah, I'm one of those that doesn't sit on #python-dev due to the lack of a persistently connected machine, so an email would work better (unless we want to be trendy and write a bot for Slack/Skype/FB Messenger :).
What are you think about backporting recent regrtest to 2.7? Most needed features to me are the -m and -G options.
Regrtest changed a lot in python 3.6 (new test.libregrtest library). I suggest to start from python 3.5.
For -m: if it doesn't need to modify the unittest module, I agree.
I don't know -G option.
Would be nice to add a feature for running every test in separate subprocess. This will isolate the effect of failed tests.
See my email :-) I proposed to modify -j1 to run tests in subrpocesses. I even mentionned my issue.
I suggest to use -jN on all buildbot, at least -j1.
Maybe -j2 is even better since many tests are waiting on IO or simple sleep.
Both ideas seems reasonable.
participants (2)
-
Brett Cannon -
Victor Stinner