[core-workflow] PEP 512: migrating hg.python.org to GitHub

[Martin Panter]

On 17 January 2016 at 20:48, Brett Cannon <brett at python.org> wrote:
> Rationale
> =========
> . . .
> The overarching goal of this migration is to improve the development
> process to the extent that a core developer can go from external
> contribution submission through all the steps leading to committing
> said contribution all from within a browser on a tablet with WiFi.

Later on, at least for the main “cpython” repository, you mention
maintaining a linear history, avoiding the automatic Git Hub merge
button, and cherry-picking between branches. I guess you would need
the commit bot to help do all this from a browser. If so, mention
that, otherwise this gives the impression that people will Git Hub’s
merge button, which seems to contradict later sections.

> Document steps to commit a pull request
> '''''''''''''''''''''''''''''''''''''''
> During the process of choosing a new development workflow, it was
> decided that a linear history is desired. This means that the
> convenient "Merge" button in GitHub pull requests is undesireable, as
> it creates a merge commit along with all of the contributor's
> individual commits (this does not affect the other repositories where
> the desire for a linear history doesn't exist).

Please clarify whether this linear history is just avoiding the
suprious merge commits that Git Hub can add for each pull request
(merging a pull request with its parent commit), or whether we are
going to stop merging maintainence branches into master, and do
cherry-picks instead.

> Linking a pull request to an issue
> ++++++++++++++++++++++++++++++++++
> . . .
> (technically it should be a many-to-many association for when a
> single fix solves multiple issues, but this is fairly rare and issues
> can be merged into one using the ``Superceder`` field on the issue
> tracker).

Spelling: ``Super[s]eder``

> Status
> ======
> . . .
>  Repositories whose build steps need updating:

There is some stray indentation starting here which seems to be
messing with the markup.

> The fate of hg.python.org
> -------------------------
> With the code repositories moving over to Git [#git]_, there is no
> technical need to keep hg.python.org [#h.p.o]_ running.

I presume this means other repositories will be migrated somewhere
else too? For instance, I recently had to update the
“pythontestdotnet” repository.

> Tools and commands to move from Mercurial to Git
> ------------------------------------------------
> A decision needs to be made on exactly what tooling and what commands
> involving those tools will be used to convert a Mercurial repository
> to Git. Currently a suggestion has been made to use
> https://github.com/frej/fast-export. Another suggestion is to use
> https://github.com/felipec/git-remote-hg. Finally,
> http://hg-git.github.io/ has been suggested.

The migration to Git might be a good opportunity to clean up some of
the older Subversion history. I would like to investigate this. In
particular, rewriting svnmerge commits as proper Git merges, and
restoring the missing history for merges and imports from feature
branches.

On the other hand, there is already a Git mirror
<https://github.com/python/cpython> which many seem to be already
using. Perhaps it would be good to ensure the commit hashes used there
are kept current. Which tool is used to update that mirror? Are there
any deficiencies that would mean we need to use a different tool,
possibly affecting the commit hashes?

> Separate Python 2 and Python 3 repositories
> -------------------------------------------
> It was discussed whether separate repositories for Python 2 and
> Python 3 were desired. The thinking was that this would shrink the
> overall repository size which benefits people with slow Internet
> connections or small bandwidth caps.
>
> In the end it was decided that it was easier logistically to simply
> keep all of CPython's history in a single repository.

Agreed. If people really only want one of the branches, they can set
Git to only download from that branch. And Git supports shallow clones
(only download the most recent commit, or N commits deep), although
some functions may not work in this mode (but apparently things have
improved since I learnt about it).