[core-workflow] Questions about the proposed workflows

[Brett Cannon]

On Mon, 14 Dec 2015 at 08:48 Donald Stufft <donald at stufft.io> wrote:

>
> > On Dec 14, 2015, at 11:46 AM, Barry Warsaw <barry at python.org> wrote:
> >
> > On Dec 14, 2015, at 11:35 AM, Donald Stufft wrote:
> >
> >> You don’t really need the merge commit if you’re doing squash merges
> >
> > Just to be clear though, with a GitHub choice, you'd either have to
> accept
> > merge commits, or do the squash merges locally and then push master
> because
> > they aren't supported by GH's u/i, right?
> >
>
> Correct. Where “locally” could also include a robot to do merges based on
> a comment left on the PR, like “Ok to Merge”. There is no built in option
> to do anything but ``git merge —no-ff`` in Github’s UI.
>

A point I want to make here is that the motivating factor for all of this
potential dev workflow upheaval is to increase our patch review/acceptance
throughput. If this comes at the cost of a very clean log then I say so be
it; an open source project thrives or dies based on how well it can manage
its relationship with external contributors as they are the future core
contributors (and this is especially true for projects like Python where
there is no corporate sponsor making sure the project stays staffed). From
my perspective (and seemingly that of the community based on what people
said during Guido's PyCon keynote), we are not doing a good job at managing
this relationship. For me this is "practicality vs purity" in terms of
"patch throughput vs log cleanliness" and I think the former should trump
the latter if we are not going to end up being a project where only the
truly dedicated contribute and we persistently end up with only core devs
contributing (which won't help scale for bugfixes).

Having said that, I get the desire to have a clean history. Based on the
fact no one has said "I hate squashed commits" compared to "I hate merge
commits", I want to see if there is a way to make it so that everyone gets
what they want; ease-of-use through the browser while getting a clean
history. I think it may be possible if I'm not misunderstanding technical
possibilities of GitHub or GitLab using a bot-based workflow.

Let's say Alice submits a PR against master to fix a bug that should get
backported to 3.5  which I figure this is probably the most complicated
common-case we have (the PR starts off with the Merge button being yellow
because we just flag all PRs as not to be merged by GitHub's workflow). Eve
does a code review, leading to various commits being made by Alice in her
branch. Everything gets to a state where the *code* is in a state that Eve
is happy with the PR. At this point some CI has run to verify that all
tests (at least) pass on master. We still need to make an entry for
Misc/NEWS, get Alice's changes into master and into 3.5. We leave a comment
in the PR along the lines of:
```
/black-knight master 3.5

Issue #12345: Fixed some thingy somehow.

Through the magic of common sense the issue the bug was made as a dead as a
parrot.

/news Issue #213245: Fixed some thingy.
```
(we can squabble over the bot's name being something else like
non-shall-pass instead, but for my money if we have a bot that guards
Python's repo is has to be a Holy Grail & black knight reference)

What that comment would do is trigger a bot that would grab the patch for
the PR, apply it against master, generate a NEWS entry file for everything
following `/news` (i.e., using Larry's proposed file-per-change NEWS
solution to avoid conflicts), and commit to master using as a message
everything between `/black-knight` and `/news`. It would then cherry-pick
the new change in master and apply it to the 3.5 branch. After all of this,
the bot pushes the branches to origin and closes the PR with an appropriate
message. Had there been a merge problem with the cherry pick then it would
be dropped, the PR left open, and an appropriate message added to the PR
(and maybe even an appropriate label or milestone added so no one forgets
why the PR is open).

This kind of workflow gets us a clean history, unique NEWS entries per
commit, and merges/cherry picks across versions that are conflict-free.
There is also nothing stopping people from doing the work from the
command-line from a checkout if they want/need to. Heck, we can even have
black-knight add a comment to every PR that links to the devguide on how to
do it manually if we want.

I realize some things could be optimized and some niceties added, but what
I propose above I think would get us a workflow that's easy enough that one
could accept a patch on their lunch break without much issue and hence
increase our patch acceptance throughput.

This also means neither GitHub or GitLab offer any specific benefit over
each other from what I can tell (if we dropped unique NEWS entries and did
cherry picks manually then I think GitLab EE gets us web-based squashing if
I understand things properly). But this bot-based approach gets us the
common-case managed entirely in the browser with a clean history.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/8b911a04/attachment.html>