<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 20, 2015 at 7:15 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 July 2015 at 05:49, Brett Cannon <<a href="mailto:bcannon@gmail.com" target="_blank">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>
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></blockquote><div><br></div><div>I wasn't conflating them so much as not worrying about #1 as I know that's not a hard problem to solve like the CPython-specific workflow is.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>OK, then let's choose the devguide or the PEPs to test Kalithea out on and see how it goes since no one has experience with the service while I bet everyone has experience with at least GitHub. If you can get whomever has done the most amount of work on the devguide lately to sign off on it -- probably Carol Willing -- then I say get a test instance of <a href="http://forge.python.org">forge.python.org</a> up for the devguide and let's see what working with Kalithea is like (and it also gets us more new contributor feedback than the PEPs would while also not frustrating Guido when he deals with peps@ =).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>Right. Basic coverage is better than no coverage for initial patch testing (after core dev approval).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>SGTM</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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></blockquote><div><br></div><div>Definitely wouldn't hurt, and it does raise their profiles on the issue tracker. </div></div></div>