<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 14 Dec 2015 at 08:48 Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Dec 14, 2015, at 11:46 AM, Barry Warsaw <<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>> wrote:<br>
><br>
> On Dec 14, 2015, at 11:35 AM, Donald Stufft wrote:<br>
><br>
>> You don’t really need the merge commit if you’re doing squash merges<br>
><br>
> Just to be clear though, with a GitHub choice, you'd either have to accept<br>
> merge commits, or do the squash merges locally and then push master because<br>
> they aren't supported by GH's u/i, right?<br>
><br>
<br>
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.<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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 <b>code</b> 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:</div><div>```</div><div>/black-knight master 3.5</div><div><br></div><div>Issue #12345: Fixed some thingy somehow.</div><div><br></div><div>Through the magic of common sense the issue the bug was made as a dead as a parrot.</div><div><br></div><div>/news Issue #213245: Fixed some thingy.</div><div>```</div><div>(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)</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>