<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 30.05.2018 16:36, Nick Coghlan wrote:<br>
<blockquote type="cite"
cite="mid:CADiSq7cz7iofuev_TC6ZUtHqE0zbrjYRR0bSj+9bec1UdG-tLA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 30 May 2018 at 22:30, Ivan Pozdeev
via Python-Dev <span dir="ltr"><<a
href="mailto:python-dev@python.org" target="_blank"
moz-do-not-send="true">python-dev@python.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
What's the big idea of separate buildbots anyway? I
thought the purpose of CI is to test everything _before_<br>
it breaks the main codebase. Then it's the job of the
contributor rather than maintainer to fix any breakages.<br>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, maybe making them be driven by Github checks would be
a better time investment.<br>
Especially since we've got VSTS checks just recently, so
whoever was doing that still knows how to interface with
this Github machinery.<br>
<br>
If the bots cancel a previous build if a new one for the
same PR arrives, this will not lead to a significant load
difference 'cuz the number of<br>
actively developed PRs is stable and roughly equal to the
number of merges according to the open/closed tickets
dynamics.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote>
<div><br>
</div>
<div>There are a few key details here:</div>
<div><br>
</div>
<div>1. We currently need to run post-merge CI anyway, as
we're not doing linearised commits (where core devs just
approve a change without merging it, and then a gating
system like Zuul ensures that the tests are run against
the latest combination of the target branch and the PR
before merging the change)</div>
</div>
</div>
</div>
</blockquote>
<p>This is the only point here that looks valid (others can be
refuted). This technique limits the achievable commit rate by
1/testing_time . Our average rate probably fits into this, though
it still means delays.<br>
</p>
<blockquote type="cite"
cite="mid:CADiSq7cz7iofuev_TC6ZUtHqE0zbrjYRR0bSj+9bec1UdG-tLA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>2. Since the buildbots are running on donated dedicated
machines (rather than throwaway instances from a dynamic
CI provider), we need to review the code before we let it
run on the contributed systems</div>
<div>3. The buildbot instances run *1* build at a time,
which would lead to major PR merging bottlenecks during
sprints if we made them a gating requirement<br>
</div>
<div>4. For the vast majority of PRs, the post-merge
cross-platform testing is a formality, since the code
being modified is using lower level cross-platform APIs
elsewhere in the standard library, so if it works on
Windows, Linux, and Mac OS X, it will work everywhere
Python runs<br>
</div>
<div>5. We generally don't *want* to burden new contributors
with the task of dealing with the less common (or harder
to target) platforms outside the big 3 - when they do
break, it often takes a non-trivial amount of platform
knowledge to understand what's different about the
platform in question<br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Nick.</div>
<div><br>
</div>
<div>P.S. That said, if VSTS or Travis were to offer FreeBSD
as an option for pre-merge CI, I'd suggest we enable it,
at least in an advisory capacity - it's a better check
against Linux-specific assumptions creeping into the code
base than Mac OS X, since the latter is regularly
different enough from other *nix systems that we need to
give it dedicated code paths.<br>
</div>
<br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">Nick
Coghlan | <a href="mailto:ncoghlan@gmail.com"
target="_blank" moz-do-not-send="true">ncoghlan@gmail.com</a>
| Brisbane, Australia</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Ivan</pre>
</body>
</html>