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

[Donald Stufft]

> On Nov 30, 2014, at 2:19 PM, Brett Cannon <brett at python.org> wrote:
> 
> All very true, but if we can't improve both sides then we are simply going to end up with even more patches that we take a while to get around to. I want to end up with a solution that advances the situation for *both* committers and non-committers and I feel like that is being lost in the discussion somewhat. As the person who pushed for a migration to DVCS for non-committers I totally support improving the workflow for non-committers, but not at the cost of ignoring the latter half of the contribution workflow of committers which is a chronic problem.
> 
> As the PEP points out, the devguide, devinabox, and the PEPs have such a shallow development process that hosting them on Bitbucket wouldn't be a big thing. But if we don't view this as a long-term step towards moving cpython development somehow we are bifurcating our code contributors between git and hg which will be annoying. Now it could be argued that it doesn't matter for the peps and devguide since they are purely text and can be done easily through a web UI and a simple CI in Travis can be set up to make sure that the docs compile cleanly. But moving devinabox where there is going to be a code checkout in order to execute code for testing, etc. will be an issue.
> 
> So I guess my view is +0 for doc-only repos on GitHub as long as we make it clear we are doing it with the expectation that people will do everything through the web UI and never have to know git. But I can't advocate moving code over without moving ALL repos over to git -- hosting location doesn't matter to me -- to prevent having to know both DVCSs in order to do coding work related to Python; the cpython repo shouldn't become this vaunted repo that is special and so it's in hg long-term but everything else is on git.


So a goal of mine here is to sort of use these as a bit of a test bed. Moving CPython itself is a big and drastic change with a lot of implications, but moving the “support” repositories is not nearly as much, especially with a read only mirror on hg.python.org <http://hg.python.org/> which would allow things like the PEP rendering on www.python.org <http://www.python.org/> to stay the same if we wanted to. My hope was that we’d try this out, see how it works out, and if it seems to be a good thing, then at a later time we can either look at moving CPython itself or decide if it makes sense to do something different. Maybe this should be spelled out in the PEP? 

I’ve seen a few people say they were -1 because they didn’t want to split between hg on the CPython side and git on the supporting repos side. I’m not sure you can really get away from that because we’re *already* in that situation, things like the docs building script is a Git repo on Github, the python infrastructure itself is a git repo on Github, the new python.org <http://python.org/> website is a git repo on Github, the future PyPI is a git repo on GitHub. 

IOW I’m not sure what the best way forward is. I think moving to these tools for *all* repos is likely to be in the best interests of making things better for both sides of that coin however I didn’t want to go wholesale and try and make everything switch at all at once. If you think it makes sense to drop devinabox and make the dividing line between Code and not code (although I’d argue that line is already crossed with other code things already being on github) that’s fine with me. Or I can expand the scope if people think that makes more sense in the PEP too.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141130/4938a248/attachment.html>