<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 14 Jun 2017 at 07:46 Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The CPython workflow was enhanced to get pre-commit CI checks. That's<br>
a huge win, thank you for that... But, sometimes, a change can still<br>
break many buildbots, bugs which weren't catched by pre-commit checks<br>
(Travis CI/Linux and AppVeyor/Windows). Buildbots cover much more<br>
different architectures and platforms.<br></blockquote><div><br></div><div>There's also macOS if you look at the Travis results manually.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I spend a significant amount of time to maintain the sanity of our<br>
buildbots. Sometimes, it can take me up to 3 days on a week (of 5<br>
working days). It's annoying to see new regressions while I'm trying<br>
hard to fix old ones :-(<br>
<br>
So I would like to set a new rule: if I'm unable to fix buildbots<br>
failures caused by a recent change quickly (say, in less than 2<br>
hours), I propose to revert the change.<br>
<br>
It doesn't mean that the commit is bad and must not be merged ever.<br>
No. It would just mean that we need time to work on fixing the issue,<br>
and it shouldn't impact other pending changes, to keep a sane master<br>
branch.<br>
<br>
What do you think? Would you be ok with such rule?<br></blockquote><div><br></div><div>I'm +1 on it. We have always expected people to watch the buildbots after a commit to make sure nothing horrible happened. And leaving a branch broken just makes fixing it harder due to code change and it masks potential failures from subsequent commits that happen to manifest themselves as a similar failure.</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A recent example is Nick Coghlan's implementation of the PEP 538:<br>
basically, it broke all buildbots... except of Linux and Windows :-)<br>
And it will take a few more days to fix all failures. Well, we are<br>
working on fixing these issues, so I don't want to revert this change.<br>
It's just an example of a single change which broke many buildbots.<br>
The PEP 538 depends a lot on the platform, so I'm not surprised to see<br>
different failures per platforms ;-)<br>
<br>
By "buildbot failure", I mean a red buildbot failing because of<br>
compilation error or failed test suite. But I would prefer to ignore<br>
failures of the Refleak buildbots since these ones are not stable<br>
(even if there are less and less ref leaks in master, and these<br>
buildbots already catched recent regressions!).<br>
<br>
If the rule is approved, I plan to announce it on python-dev to be transparent.<br>
<br>
Victor<br>
_______________________________________________<br>
python-committers mailing list<br>
<a href="mailto:python-committers@python.org" target="_blank">python-committers@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-committers" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-committers</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>