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)

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

Now as for whether we should move the repos, I see two possibilities to help make that decision. One is we end up with 3 PEPs corresponding to the 3 proposals outlined above, get them done before PyCon, and then we have a discussion at the language summit where we can either make a decision or see what the pulse at the conference and sprints then make a decision shortly thereafter (I can moderate the summit discussion to keep this on-task and minimize the rambling; if Guido wants I can even make the final call since I have already played the role of "villain" for our issue tracker and hg decisions).

The other option is we take each one of the 3 proposed repos and pilot/experiment with them on a different platform. I would put peps on GitHub (as per Guido's comment of getting PRs from there already), the devguide on Bitbucket, and leave devinabox on hg.python.org but with the motivation of getting better tooling in place to contribute to it. We can then see if anything changes between now and PyCon and then discuss what occurred there (if we can't get the word out about this experiment and get new tooling up and going on the issue tracker in the next 4 months then that's another data point about how much people do/don't care about any of this). Obviously if we end up needing more time we don't have to make a decision at PyCon, but it's a good goal to have. I don't think we can cleanly replicate a single repo on all three solutions as I sure don't want to deal with that merging fun (unless someone comes forward to be basically a "release manager" for one of the repos to make that experiment happen).

On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan <ncoghlan@gmail.com> wrote:

On 2 December 2014 at 01:38, Guido van Rossum <guido@python.org> wrote:
> As far as I'm concerned I'm just waiting for your decision now.

The RhodeCode team got in touch with me offline to suggest the
possibility of using RhodeCode Enterprise as a self-hosted solution
rather than a volunteer-supported installation of Kallithea. I'll be
talking to them tomorrow, and if that discussion goes well, will
update PEP 474 (and potentially PEP 462) accordingly.

Given that that would take away the "volunteer supported" vs
"commercially supported" distinction between self-hosting and using
GitHub (as well as potentially building a useful relationship that may
help us resolve other workflow issues in the future), I'd like us to
hold off on any significant decisions regarding the fate of any of the
repos until I've had a chance to incorporate the results of that
discussion into my proposals.

As described in PEP 474, I'm aware of the Mercurial team's concerns
with RhodeCode's current licensing, but still consider it a superior
alternative to an outright proprietary solution that doesn't get us
any closer to solving the workflow problems with the main CPython
repo.

Regards,
Nick.

P.S. I'll also bring up some of the RFEs raised in this discussion
around making it possible for folks to submit pull requests via
GitHub/BitBucket, even if the master repositories are hosted on PSF
infrastructure.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia