On Tue Dec 02 2014 at 1:05:22 PM Guido van Rossum <gu...@python.org> wrote:
> 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. > Well, if I'm going to be the Great Decider on this then I can say upfront I'm taking a pragmatic view of preferring open but not mandating it, preferring hg over git but not ruling out a switch, preferring Python-based tools but not viewing it as a negative to not use Python, etc. I would like to think I have earned somewhat of a reputation of being level-headed and so none of this should really be a surprise to anyone. So if we did have a discussion at the summit and someone decided to argue for FLOSS vs. not as a key factor then I would politely cut them off and say that doesn't matter to me and move on. As I said, I would moderate the conversation to keep it on-task and not waste my time with points that have already been made and flagged by me and you as not deal-breakers. And any votes would be to gauge the feeling of the room and not as a binding decision; I assume either me or someone else is going to be the dictator on this and this won't be a majority decision. > > 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. :-) > What about me doing something that *I* regret like taking this on? =) -Brett > > --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
