> On Nov 30, 2014, at 3:26 PM, Brett Cannon <br...@python.org> wrote: > > > > On Sun Nov 30 2014 at 2:33:35 PM Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > >> On Nov 30, 2014, at 2:19 PM, Brett Cannon <br...@python.org >> <mailto:br...@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. > > 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).
I’m not sure what you’re proposing here. If devinabox checks out peps, devguide, and cpython aren’t they going to have to use git and hg both unless we move all of those repositories together? Beyond just the tools the status quo of those is that if you do make a change you have different ways to submit a contribution depending on which repository it is. > > > > 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”. What do you mean by “docs”, is that the devguide and PEPs repository? Here’s another idea for an experiment that might be more generally useful. As we've said there are two sides to the coin here, non-comitters and comitters, a lot of the benefit of moving to Github is focused at non-comitters although there are benefits for comitters themselves. Django hosts it's git repository on Github and it's issue tracker is Trac. Although it doesn't require an issue to be created for small issues, you can just send a PR. What if we focused an experiment on the benefits to non-comitters? It's possible to maintain a git mirror of a Mercurial repository, in fact we already have that at github.com/python/cpython. What if we permit people to make PRs against that repository, and then take those PRs and paste them into roundup? Sort of like the "Remote hg repo" field. Then we can create some integration that would post a comment to the ticket whenever that PR is updated (sort of like the notification that happens when a new patch is uploaded). The cannonical repository would still be hg.python.org and in order to actually commit the PR commiters would need to turn the PR into a patch (trivially easy, just add .diff or .patch to the PR URL). If we ever move CPython to git (and Github) this sort of integration is going to be required anyways unless we plan on moving the issue tracker as well which I don't think we would since the Github issues are not fully featured enough for us. This would give us some real information on how people would prefer to contribute I think. If people start sending a lot of patches using Github PRs then we can look at moving the possibility of moving everything whole hog over to the git / Github. If people end up not really using it, or it doesn't seem to be actually useful we can look at disabling or (or keeping it around for people who like to use it). I still think moving at least the PEPs and devguide repository over to git / Github is a generally good idea that should be part of all of this as well. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
