The CPython workflow on GitHub

On 29/05/2017 18:30, [email protected] wrote:
> On Mon, May 29, 2017 at 3:07 AM, Jeff Allen <[email protected]> wrote:
>>   * Although I believe I could commit directly to
>>     https://github.com/jython/jython3, or a branch in there, do we agree
>>     a better practice is to fork, branch and create a PR for a "feature"
>>     (groups of related commits)? Even if I then accept my own PR, it
>>     seems to give us a better audit trail, integration test, squash
>>     point, etc.. A separate thread/discussion is due about workflow,
>>     naming, etc..
> That sounds good to me. I haven't studied CPython's workflow for
> github, but in general I think we should try to do what they do.
>
Since I wrote, I've been looking at CPython's workflow now based on GitHub.

For the contributor there are straightforward instructions here: 
https://docs.python.org/devguide/ that include fork, branch and PR as I 
expected. Interestingly we're asked to raise an issue on tracker at 
bugs.python.org, not at GitHub, so it's not just a repository of 
pre-existing issues. Here's an example of that working: 
https://github.com/python/cpython/pull/1853

There are some helpful bots, including an integration with 
bugs.python.org that checks for a contributor agreement. I think we 
could not copy this unless we bring our tracker up to the same state as 
the CPython one. I like the bot that @mentions core developers as 
reviewers, based on who worked on the files you touched.

Behind the scenes it is more complicated. A description of the branching 
and tagging is here: 
https://docs.python.org/devguide/devcycle.html#branches, including some 
rules about what alpha, beta, RC should mean in terms of acceptable 
commits. This all looks very sensible to me and I imagine it is 
essentially the same as it was for Mercurial.

More examples ...

Here Serhiy Storchaka makes a PR for a change consisting of (as I write) 
a couple of commits. (https://github.com/python/cpython/pull/1851) Even 
though he is a core developer, and the master branch is the active 
development branch, the work originates on a feature branch in his own 
forked repo. This gives us a chance to comment and him a chance to see 
it tested by Travis etc.. If I've understood the rules, Serhiy would be 
able to merge this into the master branch on his own approval.

In another example, the feature branch is on the central repository 
(https://github.com/python/cpython/pull/1855). I think Alex has got the 
process wrong, and it should have been on his own fork, but maybe 
there's a good reason, and I think there's no permanent harm.

Here's a more complicated example in which a change from a contributor 
is committed on master (by Serhiy) and then cherry-picked by Mariatta 
onto the 2.7, 3.5 and 3.6 branches. 
(https://github.com/python/cpython/pull/1019) This picking happens via 
branches on her own repository. The merge doesn't go smoothly on 2.7, 
but the problem is resolved with help from Serhiy. 
(https://github.com/python/cpython/pull/1289) Thus in spite of the 
difficulty, nothing hits the 2.7 branch until it is correct. Mariatta's 
branches are not visible any more since she is able to delete them after 
the merge.

Jeff






------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot