Thanks for taking charge, Brett. I personally think this shouldn't be brought up at the summit -- it's likely to just cause lots of heat about git vs. hg, free vs. not-free, "loyalty" to free or open tools, the weighing of core committers' preferences vs. outside contributors' preferences, GitHub's diversity track record, with no new information added. Even if we *just* had a vote by show-of-hands at the summit that would just upset those who couldn't be present.
But I'll leave that up to you. The only thing I ask you is not to give me the last word. I might just do something you regret. :-) --Guido On Tue, Dec 2, 2014 at 8:50 AM, Brett Cannon <br...@python.org> wrote: > 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 <ncogh...@gmail.com> wrote: > >> On 2 December 2014 at 01:38, Guido van Rossum <gu...@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 | ncogh...@gmail.com | Brisbane, Australia >> > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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