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

[Brett Cannon]

On Sun, 17 Jan 2016 at 17:37 Martin Panter <vadmium+py at gmail.com> wrote:

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


Yes.


> If so, mention
> that, otherwise this gives the impression that people will Git Hub’s
> merge button, which seems to contradict later sections.
>

Well, you get it for some of the repositories, just not cpython. And I
don't entirely agree that the sentence suggests GitHub's built-in browser
workflow is the answer, just that *some* in-browser workflow is desired.


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


Both is the current plan.


>


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

The assumption is everything will move long-term instead of fragmenting
between GitHub and hg.python.org.


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


I'm not going to worry about that if the mirror was not done accurately.


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

I don't know. Eli Bendersky set up that mirror and he has said previously
that he just did the bare minimum to get it working and didn't worry too
much about correctness, etc.

-Brett


>
> > 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160118/4b5f6df7/attachment.html>