Hi,
On Fri, Jan 1, 2016 at 9:21 PM, Brett Cannon
I don't think this will be a shock to anyone who has followed the discussion on this list. The decision is essentially based on:
No major distinguishing features between GitHub or GitLab Familiarity amongst core devs -- and external contributors -- with GitHub Guido prefers GitHub
Neither platform had some mind-blowing feature(s) that really made them stand out from each other such that it would greatly simplify our lives if we chose one platform over another. I obviously was really hoping there was going to be something I missed, but nothing ever came up (and no, being open source is not enough of a feature; as I said when I started this process, being open source would help break ties or minor lead of one tool but not be a deciding factor).
But what Github does have over GitLab is familiarity. While there were people who publicly said they would prefer not to go with GitHub but would begrudgingly use it if we chose to go that route, I had multiple core devs email me privately saying they hoped I would choose GitHub. I think most of that stemmed from having used GitHub for other open source projects and/or work, making even dormant core devs say they would be able to become active again if we switched to GitHub thanks to eliminating the barrier of having to keep up with our custom workflow for code reviews and using hg for commits. And while I said it wasn't a goal to make things easier for external contributors, I also can't ignore the fact that the vast majority of people out there who might want to help out are already familiar with GitHub.
And at least for me, the fact Guido prefers GitHub means something. While Guido himself would say I shouldn't really worry about his preferences since he is only an occasional contributor at this point, I believe that it's important that our BDFL actually like contributing to his own programming language rather than potentially alienating him because he finds the process burdensome.
So that's why I have chosen GitHub over GitLab. Please realize that this is choosing GitHub to provide repository hosting and code review; we are not moving our issue tracker, nor are we moving our wiki. And the long-term plan is to set up a bot that will handle our commit workflow which will help isolate us from any repository hosting platform we are on and making moving easier in the future (and short-term people will use the command-line and that's totally platform-agnostic).
Thanks to everyone who contributed to this decision, especially Donald, Barry, and Nick for making the proposals we had to work from.
We can start the discussion of how we want to handle the transition next week, but I'm going to try and step away from this whole workflow topic until Monday so I can spend the last couple of days of my vacation not thinking about this stuff. :)
This will likely require a new PEP, that should cover: 1) the new workflow (including how to handle reviews -- see below); 2) the steps required for the migration and a timeline; 3) a list of things that will break and/or that will need to be added/replaced before/during/after the migration; 4) the fate of hg.python.org; Some of these things might already be covered by existing PEPs, but I don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost among all the competing PEPs and multiple threads across at least a couple different MLs :). Above you said that GitHub will be used for reviews but we will keep using our bug tracker. This leads to the following questions: * Do GitHub reviews only work for pull requests? * Are we still going to support uploading diffs/patches to the tracker (short term and long term)? * If so, how/where are we going to review those diffs/patches? * Will patches be automatically converted to pull requests, or pull requests converted to patches and attached to b.p.o issues? * Are there plans to migrate existing Rietveld reviews to GitHub and shut Rietveld down for good? * If not, will Rietveld stay around and be read-only? Or will it still be used for patches uploaded to b.p.o? * What else is needed to integrate GitHub and b.p.o? About points 3 of the initial list, these are some examples of things that will need to be added/updated/replaced: * the hgroundup hook[2] that post messages to b.p.o when a commit includes an issue number needs to be replaced; * the hgirker hook[3] used for deadparrot on #python-dev needs to be replaced (probably there is already an irker-git hook that can be used/adapted); * the hgbuildbot[4] hook that triggers the buildbots on commit needs to be replaced; * other hg hooks[5] might need to be rewritten/replaced; * the script[6] that generates bug tracker links to hg.p.o needs to be updated (for both cs ids and paths); * the hg code that converts issue links in commit messages to b.p.o links needs to be replaced; * other places where issue numbers appears on GitHub should generate links to b.p.o; * the hg-cpydev hg extension [7] should be ported to git (optional); * the buildbots need to be updated if they are going to pull the source from github and use git; * the bug tracker will need to be updated to interact with github; * the devguide needs to be updated (both to cover the new workflow and update links/commands); FWIW next weekend (9-10 January) we are organizing a sprint in Helsinki, and I'm planning to work on the bug tracker, so I might be able to start addressing some of these points. Best Regards, Ezio Melotti P.S. enjoy your last few days of vacation while you can ;) [0]: https://www.python.org/dev/peps/pep-0507/ [1]: https://www.python.org/dev/peps/pep-0481/ [2]: https://hg.python.org/hooks/file/tip/hgroundup.py [3]: https://hg.python.org/hooks/file/tip/hgirker.py [4]: https://hg.python.org/hooks/file/tip/hgbuildbot.py [5]: https://hg.python.org/hooks/file/tip [6]: https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.p... [7]: https://bitbucket.org/introom/hg-cpydev