<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 15 Jun 2017 at 06:39 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">2017-06-15 5:31 GMT+02:00 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>>:<br>
> I'm not necessarily opposed to such a policy change, but if folks<br>
> really want guaranteed green post-merge buildbots for all platforms<br>
> (rather than just guaranteed green for Linux & Windows, sometimes red<br>
> for everything else), then I think a better place to focus effort<br>
> would be in making it easier for us to test things across the full<br>
> BuildBot fleet in pre-merge CI.<br>
><br>
> For example, something that would be genuinely helpful would be a bot<br>
> monitoring PR comments that could automate the "custom-build" dance<br>
> for core developers (i.e. we'd be able to write something like<br>
> "BuildBot: test custom build", and it would go away, kick off a custom<br>
> BuildBot run by pushing the PR to the "custom-build" branch, and then<br>
> report back the links for failed builds like<br>
> <a href="http://buildbot.python.org/all/builders/x86%20Tiger%20custom/builds/5" rel="noreferrer" target="_blank">http://buildbot.python.org/all/builders/x86%20Tiger%20custom/builds/5</a><br>
> )<br>
<br>
I don't think that buildbots have enough resources to run tests on<br>
each PR. We get too many PR and each PR is updated regularly. On some<br>
buildbots, a single build can take 1 hour (or longer)... Moreover,<br>
that's an idea, but we need "someone" to do the job. I don't know<br>
anyone available to do it.<br>
<br>
I'm proposing a pragmatic solution to a concrete issue. I'm just to do<br>
by best with our limited resources (human and CPU time). Again,<br>
failures on random platforms not caught by our pre-commit CI occur,<br>
but are -hopefully- rare!<br>
<br>
I dislike having a long list of "nice to have" list for our infra. I<br>
prefer to focus on the existing bricks and don't put too much pressure<br>
on people who give their time to care of our tooling and infra ;-)<br></blockquote><div><br></div><div>I at least appreciate that. :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(Yes, I would also prefer to have a fleet of buildbots at the<br>
pre-commit stage if I can get it for free :-))<br></blockquote><div><br></div><div>Yes, that would definitely be nice, especially if we could get it working in the cloud to handle load and a wider range of OSs. But this is all orthogonal to the question of "revert immediately or not?". It's also not worth discussing here as it's totally wishful thinking for the foreseeable future (that's what the core-workflow issue tracker is for ;) .<br><br></div><div>-Brett<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>