<div dir="ltr">Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and it's a dead-end fork because the Rietveld project itself only supports App Engine, but Martin's fork runs on our own server infrastructure. These environments are *very* different (App Engine has its own unique noSQL  API) and it took a major hack (not by MvL) to get it to work outside App Engine. That fork is not supported, and hence our Rietveld installation still has various bugs that have long been squashed in the main Rietveld repo. (And no, I don't have time to help with this -- my recommendation is to move off Rietveld to something supported.)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 2, 2014 at 2:33 PM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> So I was waiting for Nick to say what he wanted to do for the peps repo<br>
> since I view it as I get 2/3 of the choices and he gets the other third.<br>
><br>
> The way I view it, the options are:<br>
><br>
> Move to GitHub<br>
> Move to Bitbucket<br>
> Improve our current tooling (either through new hosting setup and/or adding<br>
> first-world support for downloading PRs from GitHub/Bitbucket)<br>
<br>
</span>I'd argue that option #3 here is somewhat orthogonal to switching<br>
hosting.  It makes sense regardless unless we plan on ditching roundup<br>
and reitveld (to which I'd be opposed).<br>
<span class=""><br>
><br>
> Regardless of what we do, I think we should graduate the mirrors on GitHub<br>
> and Bitbucket to "official" -- for the proposed repos and cpython -- and get<br>
> their repos updating per-push instead of as a cron job. I also think we<br>
> should also flip on any CI we can (e.g. turn on Travis for GitHub along with<br>
> coveralls support using coverage.py's encodings trick). This will get us the<br>
> most accessible repo backups as well as the widest tool coverage for<br>
> contributors to assist them in their contributions (heck, even if we just<br>
> get regular coverage reports for Python that would be a great win out of all<br>
> of this).<br>
<br>
</span>+1 to all of this.  Doing this would allow us to move forward with<br>
GH/BB-roundup/reitveld integration (option #3) sooner rather than<br>
later, regardless of moving to other hosting.<br>
<span class=""><br>
> So do people want PEPs or experimentation first?<br>
<br>
</span>+1 to PEPs.  It's basically already happening.  I'd like to see where<br>
474/481/etc. end up, particularly with what Nick brought up earlier.<br>
<br>
Furthermore, I'm not sure how effectively we can experiment when it<br>
comes to moving hosting.  There's overhead involved that biases the<br>
outcome and in part contributes to the momentum of the initial<br>
experimental conditions.  I doubt any external solution is going to<br>
prove drastically better than another, making it harder to justify the<br>
effort to move yet again.<br>
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span></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>