[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

Eric Snow ericsnowcurrently at gmail.com
Tue Dec 2 23:33:16 CET 2014


On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon <brett at python.org> wrote:
> So I was waiting for Nick to say what he wanted to do for the peps repo
> since I view it as I get 2/3 of the choices and he gets the other third.
>
> The way I view it, the options are:
>
> Move to GitHub
> Move to Bitbucket
> Improve our current tooling (either through new hosting setup and/or adding
> first-world support for downloading PRs from GitHub/Bitbucket)

I'd argue that option #3 here is somewhat orthogonal to switching
hosting.  It makes sense regardless unless we plan on ditching roundup
and reitveld (to which I'd be opposed).

>
> Regardless of what we do, I think we should graduate the mirrors on GitHub
> and Bitbucket to "official" -- for the proposed repos and cpython -- and get
> their repos updating per-push instead of as a cron job. I also think we
> should also flip on any CI we can (e.g. turn on Travis for GitHub along with
> coveralls support using coverage.py's encodings trick). This will get us the
> most accessible repo backups as well as the widest tool coverage for
> contributors to assist them in their contributions (heck, even if we just
> get regular coverage reports for Python that would be a great win out of all
> of this).

+1 to all of this.  Doing this would allow us to move forward with
GH/BB-roundup/reitveld integration (option #3) sooner rather than
later, regardless of moving to other hosting.

> So do people want PEPs or experimentation first?

+1 to PEPs.  It's basically already happening.  I'd like to see where
474/481/etc. end up, particularly with what Nick brought up earlier.

Furthermore, I'm not sure how effectively we can experiment when it
comes to moving hosting.  There's overhead involved that biases the
outcome and in part contributes to the momentum of the initial
experimental conditions.  I doubt any external solution is going to
prove drastically better than another, making it harder to justify the
effort to move yet again.

-eric


More information about the Python-Dev mailing list