On Sun Nov 30 2014 at 2:33:35 PM Donald Stufft <donald@stufft.io> wrote:

On Nov 30, 2014, at 2:19 PM, Brett Cannon <brett@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 which would allow things like the PEP rendering on 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 website is a git repo on Github, the future PyPI is a git repo on GitHub.

That doesn't bother as that is support infrastructure around CPython but in no way directly tied to CPython releases. But devinabox, for instance, is specifically for helping people contribute to CPython, so asking people to use devinabox in git but then work in hg for some repos and git in others that devinabox checks out is just asking for trouble (e.g. devinabox checks out the peps, devguide, and cpython repos).
 
 

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.

Depends what other people think, but for me it's "we are going to move to git long-term and we are starting an experiment with docs on GitHub to see if that impacts contributions and committer maintenance at least for docs, maybe for code eventually".