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

[Guido van Rossum]

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 <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:
>
>    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 <ncoghlan at gmail.com> wrote:
>
>> On 2 December 2014 at 01:38, Guido van Rossum <guido at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>


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