<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 21, 2015 at 4:15 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21 July 2015 at 05:49, Brett Cannon <<a href="mailto:bcannon@gmail.com">bcannon@gmail.com</a>> wrote:<br>
> In my ideal workflow scenario, these are the steps a patch would take:<br>
><br>
> Issue is created<br>
> Issue is triaged to have right affected versions, etc.<br>
> Patch is uploaded<br>
> CI kicks the patch off for all branches and OSs that are affected<br>
> CI flags what branches and OSs did (not) pass or apply cleanly to<br>
> If necessary, another patch that works in a specific branch that is affected<br>
> is uploaded (obviously requires some way to flag that a patch applies to a<br>
> specific branch, deciding how to deal with Misc/NEWS, etc.)<br>
> Code review -- with a tool other than Rietveld -- from a core developer with<br>
> feedback<br>
> New version of patch uploaded, usual CI kicked off<br>
> If everything looks good and CI is green, get patch approval from a core dev<br>
> Approval submits the patch(es) to the appropriate branches<br>
> CI triggered yet again, and if tests fail then patch(es) are automatically<br>
> rolled back<br>
><br>
> Now I realize this is not about to launch immediately. There are changes to<br>
> Roundup in there, a reliable test suite that actually fails only on failures<br>
> and not because it's flaky, etc. But the key point here is that everything<br>
> that can be automated is, and code reviews can occur entirely through a<br>
> browser.<br>
<br>
</span>I think you're conflating some different issues here, at least two of<br>
which are worth separating out from each other:<br>
<br>
1. Completely online workflow for documentation editing<br>
2. Pre-commit CI for CPython<br>
<br>
Both of the current <a href="http://forge.python.org" rel="noreferrer" target="_blank">forge.python.org</a> proposals are aimed primarily at<br>
the first problem, since they start out with purely documentation<br>
repos like the developer guide and the PEPs. Hopefully we can also<br>
eventually separate out "version independent" repos for the how to<br>
guides and the tutorial. In addition to a completely online process<br>
for documentation editing, review, and approval, the other key benefit<br>
to these repos would be that *access management* would also be online,<br>
rather than requiring shell access to <a href="http://hg.python.org" rel="noreferrer" target="_blank">hg.python.org</a>.<br>
<br>
Documentation projects are a good starting point for this side of<br>
things, as they're inherently lower risk. The worst thing<br>
documentation can do is give readers bad advice, it can't force them<br>
to follow it.<br>
<br>
This means that for <a href="http://forge.python.org" rel="noreferrer" target="_blank">forge.python.org</a>, I think "What about CPython?"<br>
should be something we take into account as a "What's next?" for the<br>
service, but our near term focus should be on making things like the<br>
developer guide and PEPs trivial to suggest edits to, trivial to<br>
approve edits to, and trivial to grant approval rights over. Those<br>
levels of access (who can suggest edits, who can approve edits, who<br>
can approve edit rights for others) should also all be completely<br>
transparent and changes in them should be tracked automatically rather<br>
than requiring manual updates to a text file.<br>
<br>
Pre-commit CI for CPython is a different story - as David points out,<br>
it is *not* OK to run code on the Buildbot fleet that hasn't been<br>
approved by a core developer. Folks are trusting *us* to run code on<br>
their systems, not random developers posting patches to<br>
<a href="http://bugs.python.org" rel="noreferrer" target="_blank">bugs.python.org</a>. Noah (quite sensibly) isn't interested in getting the<br>
PSF Infrastructure team involved in running random code from the<br>
internet either.<br>
<br>
That's where the system Kushal set up in collaboration with the CentOS<br>
folks potentially comes in:<br>
<a href="https://mail.python.org/pipermail/python-dev/2015-May/140050.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/python-dev/2015-May/140050.html</a><br>
<br>
That's just a simple "smoke test" to say "Does the proposed change<br>
pass on x86_64 systems running CentOS 7?". If we could combine it with<br>
a similar system for running Windows smoke tests in Appveyor, I think<br>
we'd flush out a lot of basic cross-platform compatibility issues<br>
pre-commit, regardless of whether folks are working locally on a *nix<br>
system or a Windows one. (We wouldn't catch *everything*, because<br>
Linux is not FreeBSD is not Mac OS X, etc, but we'd catch a lot of<br>
them).<br>
<br>
At the moment, running those requires that we be logged into IRC, be<br>
approved to trigger test runs, and indicate which issue we'd like to<br>
test.<br>
<br>
If we instead had a "test" link next to patch files in Roundup, then a<br>
core developer, completely online, could:<br>
<br>
1. Read over the patch to see if we think its reasonable to smoke test<br>
2. Trigger the smoke test directly from Roundup<br>
3. Receive the results back as Roundup comments, with links to the run logs<br>
<br></blockquote><div><br></div><div>We (openshift) have similar technique developed around vagrant + jenkins where <br></div><div>we can kick of by commenting on a github PR to either run the tests or perform<br></div><div>actual merge. Both of these operation run exactly the same suite of tests,<br></div><div>but only the merge performs actual, well merging. Obviously only certain group<br>of core devs has the rights to tag the PRs. Additionally when such<br></div><div>tag/comment already exists all the new changes (eg. additional changes after review)<br></div><div>are tested/merged and this is something that should be considered in this case<br></div><div>as well (there are some slight nuances, but I don't want to go too much into details). <br>Does the tag applies always or only once, and if once how you know <br></div><div>it was applied already? So having a tag on/off future would be desirable imho.<br></div><div>I'd be happy to help triaging this problem as much as my time allows me ;)<br><br></div><div>Maciej<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As we gained further familiarity and confidence with the system, we<br>
could extend the trust for running pre-commit test runs to anyone that<br>
has been granted Developer privileges on the issue tracker, rather<br>
than restricting it specifically to core developers. (BTW, we should<br>
probably come up with an icon for folks with elevated tracker<br>
privileges - at the moment they're just marked as having signed the<br>
CLA if they aren't also CPython core developers)<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
core-workflow mailing list<br>
<a href="mailto:core-workflow@python.org">core-workflow@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/core-workflow" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/core-workflow</a><br>
This list is governed by the PSF Code of Conduct: <a href="https://www.python.org/psf/codeofconduct" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct</a><br>
</div></div></blockquote></div><br></div></div>