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

[Donald Stufft]

> On Nov 30, 2014, at 8:24 PM, Guido van Rossum <guido at python.org> wrote:
> 
> Can we please stop the hg-vs-git discussion? We've established earlier that the capabilities of the DVCS itself (hg or git) are not a differentiator, and further he-said-she-said isn't going to change anybody's opinion.
> 
> What's left is preferences of core developers, possibly capabilities of the popular websites (though BitBucket vs. GitHub seems to be a wash as well), and preferences of contributors who aren't core developers (using popularity as a proxy). It seems the preferences of the core developers are mixed, while the preferences of non-core contributors are pretty clear, so we have a problem weighing these two appropriately.
> 
> Also, let's not get distracted by the needs of the CPython repo, issue tracker, and code review tool. Arguments about core developers vs. contributors for CPython shouldn't affect the current discussion.
> 
> Next, two of the three repos mentioned in Donald's PEP 481 are owned by Brett Cannon, according to the Contact column listed on hg.python.org <http://hg.python.org/>. I propose to let Brett choose whether to keep these on hg.python.org <http://hg.python.org/>, move to BitBucket, or move to GitHub. @Brett, what say you? (Apart from "I'm tired of the whole thread." :-)
> 
> The third one is the peps repo, which has python-dev at python.org <mailto:python-dev at python.org> as Contact. It turns out that Nick is by far the largest contributor (he committed 215 of the most recent 1000 changes) so I'll let him choose.
> 
> Finally, I'd like to get a few more volunteers for the PEP editors list, preferably non-core devs: the core devs are already spread too thinly, and I really shouldn't be the one who picks new PEP numbers and checks that PEPs are well-formed according to the rules of PEP 1. A PEP editor shouldn't have to pass judgment on the contents of a PEP (though they may choose to correct spelling and grammar). Knowledge of Mercurial is a plus. :-)
> 

I’m not sure if it got lost in the discussion or if it was purposely left out. However I did come up with another idea, where we enable people to make PRs against these repositories with PR integration within roundup. Using the fact that it’s trivial to turn a PR into a patch core contributors (and the “single source of truth”) for the repositories can remain Mercurial with core contributors needing to download a .patch file from Github instead of a .patch from from Roundup. This could allow non-committers to use git if they want, including PRs but without moving things around.

The obvious cost is that since the committer side of things is still using the existing tooling there’s no “Merge button” or the other committer benefits of Github, it would strictly be enabling people who aren’t committing directly to the repository to use git and Github.

---
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/418e5dd9/attachment.html>