Now that I'm comfortable declaring the code for the CLA bot finished (
https://github.com/python/the-knights-who-say-ni), the next step is to
finalize the command(s) we are going to use to convert hg repositories to
git for migration to GitHub. Senthil, are you ready to make a final
Once I have the conversion command(s) documented in PEP 512 and I have
created the "Python core" team on GitHub for all of the current Python core
developers, I will migrate https://hg.python.org/devinabox to make sure
that everything works. After that has been verified as working I will then
look at migrating https://hg.python.org/devguide/ and
https://hg.python.org/peps/ (will take a little bit more effort for both to
get the web builds updated, and peps requires getting the PEP editors
on-board). The benchmarks repo might actually not get migrated as there is
talk of starting that repo from scratch.
It's looking like we will stay on track to get at least one repository
migrated by PyCon US!
By way of Twitter, I came across
today, and it made me realise something: we should probably add reviewing
and potentially updating the README as part of the GitHub migration.
The reason I suggest that is that with the way code hosting services like
GitHub work, the README changes from something people may read for local
development after they've already cloned the repo to instead being the main
landing page for the repo.
That means it becomes a good place to point out things like:
- the location of the main dev guide
- the issue tracker
- the communications channels
- the PSF CLA (and the need to sign it for non-trivial contributions)
That's not a blocker task, I mainly wanted to bring up the link to Nadia's
guide and the rest of the email is explaining why I think that's relevant
to us even though we already have the developer guide :)
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
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.
* 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.
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA