[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Brett Cannon
brett at python.org
Tue Dec 2 17:50:29 CET 2014
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:
1. Move to GitHub
2. Move to Bitbucket
3. 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
<https://hg.python.org/devinabox/file/1eeb96fe98f1/README#l124>). 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).
So do people want PEPs or experimentation first?
On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 2 December 2014 at 01:38, Guido van Rossum <guido at 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 at gmail.com | Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141202/2f7d696e/attachment.html>
More information about the Python-Dev
mailing list