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

[Guido van Rossum]

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.)

On Tue, Dec 2, 2014 at 2:33 PM, Eric Snow <ericsnowcurrently at gmail.com>
wrote:

> On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon <brett at 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:
> >
> > Move to GitHub
> > Move to Bitbucket
> > Improve our current tooling (either through new hosting setup and/or
> adding
> > first-world support for downloading PRs from GitHub/Bitbucket)
>
> I'd argue that option #3 here is somewhat orthogonal to switching
> hosting.  It makes sense regardless unless we plan on ditching roundup
> and reitveld (to which I'd be opposed).
>
> >
> > 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). 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).
>
> +1 to all of this.  Doing this would allow us to move forward with
> GH/BB-roundup/reitveld integration (option #3) sooner rather than
> later, regardless of moving to other hosting.
>
> > So do people want PEPs or experimentation first?
>
> +1 to PEPs.  It's basically already happening.  I'd like to see where
> 474/481/etc. end up, particularly with what Nick brought up earlier.
>
> Furthermore, I'm not sure how effectively we can experiment when it
> comes to moving hosting.  There's overhead involved that biases the
> outcome and in part contributes to the momentum of the initial
> experimental conditions.  I doubt any external solution is going to
> prove drastically better than another, making it harder to justify the
> effort to move yet again.
>
> -eric
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141202/53d2cfd4/attachment.html>