<div dir="ltr"><div><div>Thanks for taking charge, Brett.<br><br>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.<br><br></div>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. :-)<br><br></div>--Guido<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 2, 2014 at 8:50 AM, Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br><div><br></div><div>The way I view it, the options are:</div><div><ol><li>Move to GitHub</li><li>Move to Bitbucket</li><li>Improve our current tooling (either through new hosting setup and/or adding first-world support for downloading PRs from GitHub/Bitbucket)</li></ol><div>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 <a href="https://hg.python.org/devinabox/file/1eeb96fe98f1/README#l124" target="_blank">coverage.py's encodings trick</a>). 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).</div></div><div><br></div><div>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).</div><div><br></div><div>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 <a href="http://hg.python.org" target="_blank">hg.python.org</a> 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 <b>have</b> 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).</div><div><br></div><div>So do people want PEPs or experimentation first?</div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote">On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2 December 2014 at 01:38, Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
> As far as I'm concerned I'm just waiting for your decision now.<br>
<br>
The RhodeCode team got in touch with me offline to suggest the<br>
possibility of using RhodeCode Enterprise as a self-hosted solution<br>
rather than a volunteer-supported installation of Kallithea. I'll be<br>
talking to them tomorrow, and if that discussion goes well, will<br>
update PEP 474 (and potentially PEP 462) accordingly.<br>
<br>
Given that that would take away the "volunteer supported" vs<br>
"commercially supported" distinction between self-hosting and using<br>
GitHub (as well as potentially building a useful relationship that may<br>
help us resolve other workflow issues in the future), I'd like us to<br>
hold off on any significant decisions regarding the fate of any of the<br>
repos until I've had a chance to incorporate the results of that<br>
discussion into my proposals.<br>
<br>
As described in PEP 474, I'm aware of the Mercurial team's concerns<br>
with RhodeCode's current licensing, but still consider it a superior<br>
alternative to an outright proprietary solution that doesn't get us<br>
any closer to solving the workflow problems with the main CPython<br>
repo.<br>
<br>
Regards,<br>
Nick.<br>
<br>
P.S. I'll also bring up some of the RFEs raised in this discussion<br>
around making it possible for folks to submit pull requests via<br>
GitHub/BitBucket, even if the master repositories are hosted on PSF<br>
infrastructure.<br>
<br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</blockquote></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div>