[core-workflow] New Github Features

[Brett Cannon]

On Fri, 1 Apr 2016 at 12:34 Donald Stufft <donald.stufft at gmail.com> wrote:

> Just wanted to point out a few new features from GitHub that may (or may
> not!)
> be useful for Python’s use of Github:
>
> * Required status checks no longer requiring a branch to be up to date.
>
>   Previously turning on required status checks meant that to merge a branch
>   into a protected branch, you the target branch could not contain any
> commits
>   that  didn’t exist in the PR. This effectively made the feature useless
> for
>   OSS projects, but it could be useful now. Of course this would also mean
> that
>   all changes need to happen via PR instead of directly pushing to a
> protected
>   branch, so it may not still be useful for Python.
>

We have actually talked about trying to encourage all core devs to go
through code review. Obviously that still only matters, though, if you
merge through the GitHub UI, which leads to your next point ...


>
> * Squash Merges, Regular Merges, or Both.
>
>   Previously the GitHub "Merge" button would always do a regular, no fast
>   forward merge which kept all of the commits that the original author made
>   intact. However GitHub now allows a repository to decide what kind of
> merges
>   it allows, either that or sqaush merges (or it can allow both). If it
> allows
>   both then the person doing the merge gets to pick what kind of merge I
> think.
>
>   A Squash merge will be most similar to how patches used to land on Python
>   and would prevent history from getting clogged up with needless commits
> from
>   people who don't edit history to keep their PRs clean, however it might
> lose
>   history from people who do.
>

Wow! For those of you who, like me, didn't know about this, it was posted
to the GitHub blog earlier today:
https://github.com/blog/2141-squash-your-commits (I hope this isn't an
elaborate April Fools prank). I have already tried this out on the CLA bot
to see how it operates and it works as expected; you can see a PR with
multiple commits <https://github.com/python/the-knights-who-say-ni/pull/7> and
the resulting single commit
<https://github.com/python/the-knights-who-say-ni/commit/d4baec1f1e209fc341a965ac1e9204baa351d6a5>
on the repo. This looks to give Guido that linear commit history he really
wants for CPython!

The trick, though, is that this doesn't handle merges into other branches
and it doesn't cover Misc/NEWS. The question then becomes how to handle
those situations. For the merge bit, if we switched from our idea of
cherrypicking to sticking with our merge forward solution like we do in hg
then you can manually create the merge-forward PR in GitHub's web UI which
is no worse than how it operates now. And if there is a merge conflict then
you can manually check out the PR, patch it up, and then be on your merry
way. The issue with that is if your merge fails and you're not on a
computer where you can fix up the merge as that could fall on someone
else's shoulders who wants to do a merge while you wait to get home on a
computer to do the fixing. I'm not sure how often that would really happen,
though, as most merges are fairly clean.

As for Misc/NEWS, we could stick with the plan of moving to a file-based
solution but have external contributors actually write the NEWS entry. Core
devs could then request any rewrite they have for the entry which wouldn't
be a huge burden thanks to GitHub's in-browser editor. We could even go as
far as having a Misc/NEWS status check that flags when there is no
Misc/NEWS entry (that may be an issue, though, if in the future we choose
to have commits be blocked by failing status checks; won't happen until our
test suite is not flaky, though).

So this support of squash merging *may* be useful. It really depends on how
we try and support porting changes between versions and Misc/NEWS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160401/b2332d16/attachment.html>