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.
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.