Brett Cannon, who is currently in charge of Python's development process, has announced on Python core workflow mailing list that Python will be moving to GitHub. In conversation with InfoQ, Cannon explained that the process that led to the current decision went on for over a year and took into account three different proposals:
- Creating forge.python.org to host Python repositories
- Migrating to Git and GitHub and Phabricator
- Migrating to Git and GitLab
The final decision was to prefer GitHub, and came down to three main factors:
- Rough equivalence of GitHub and GitLab in terms of features; specifically, Cannon wrote, the fact that GitLab is open source was not considered in itself a deciding factor.
- Prevalence of developers familiar with GitHub amongst core developers and external contributors. On the other hand, a few developers declared themselves against moving to GitHub, but no one said they would not use it, if the community decided to go that route.
- Guido van Rossum’s preference, which Cannon considered valuable to avoid the risk of potentially alienating him, though his contribution is only occasional nowdays.
Cannon explained to InfoQ how he came to that decision:
Basically I managed this decision just like I did the previous two times I managed changes in our development process: I asked for PEPs for possible solutions to the problems, had discussions based on what was proposed (although the discussions are always very fluid and the PEPs end up acting as starting points more than detailed, up-to-date proposals as you may have noticed), set various due dates on things like test instances and when I was going to make a decision, and then I made a decision based on everything I knew at the time.
It is important to note that Python use GitHub only to provide repository hosting and code review support. This means that the issue tracker and the wiki will not be moved.
Cannon’s announcement stirred some debate among Python core developers. Stefan Krah expressed his view that actually the majority of developers on the mailing list had expressed their preference for GitLab. To this, Cannon replied that he received many comments off list in reply to his asking whether anyone would stop contributing in case GitHub was preferred. He also added that in his mind he deemed more sensible to deal with few people being upset from going to GitHub and get the positives of GitHub.
InfoQ has spoken with Brett Cannon to learn more about the benefits that this decision should bring, what the next steps are in the process, etc.
Could you summarize the benefits that Python and the Python community can have from moving to GitHub?
They are touched on in a draft PEP I’m currently writing, but the expected benefit is faster patch reviews and an easier way for people to make contributions (although the real key is the former point while the latter one is a bonus). The hope is that with all the tooling that is or can be built around GitHub we will be able to automate a lot of things the Python development team used to do manually and greatly decrease the time it takes to review a patch, hence increasing throughput (currently our biggest issue is how long external contributions languish on our issue tracker and not garnering external contributions) . Add to that the familiarity that both the development team and wider open source community seems to have with GitHub, and my hope is that everything will operate faster and in an easier fashion for all involved.
What is the status of this and what will be the next steps?
The status is I made the decision to switch Python development to GitHub on January 1, 2016 and so I’m now in the process of writing the PEP which will outline all of the steps required to migrate our various code repositories (I linked to that PEP in the previous question). Once consensus has been reached on the core-workflow mailing list that the PEP covers all of the salient details, we will begin the work.
As for specific next steps, they will revolve around the key blockers that prevent any code repository from moving. Since we will move repositories at different rates depending on what tooling they require I want to get the issues that universally block all repositories solved first, and then start working about issues specific to a repository.
You announcement stirred some debate on the python mailing list. Were you satisfied with how the discussion ended?
You seem to be referring to the discussion on the core-workflow mailing list after I announced my decision, and yes I’m satisfied with how it ended. While some would have preferred if we had chosen GitLab since it has an open source edition, everyone understood why I made my choice and have been supportive of me and the tough position I was in. People are also choosing to stay positive about this and are using the opportunity to make sure we keep our development process as platform-agnostic as possible to try and make changing the platform in the future as easy as possible (which will eventually happen; this will be the third one since I became a core developer and Python itself is now 25 years old and still going strong; there is no way we won’t switch platforms again a few years down the road).
Open source projects migrating to GitHub have become quite the norm lately. Still, aren’t you worried at the concentration of so much control power in a single company, as others do? Could this be ever a problem for Python?
It’s a worry in so much as when it happens there will be the hassle of having to change platforms (and it will happen some day). But we are only going to use GitHub to host Git repositories and code reviews. The former is easy to relocate and the latter is somewhat temporal as once a pull request is closed the history is no where near as valuable. That being said, we do plan to back up the code review history so that if we have to relocate we can take any active code reviews with us since the review history has value even once a contribution is accepted. If GitHub didn’t have an open API to access our data and kept it in a walled garden they would not have been considered to begin with. Plus with platforms like GitLab having tooling to relocate your project – including pull requests – to their platform, we know that we wouldn’t lose anything but time if we needed to leave GitHub in a hurry. It also helps that we are not migrating our issue tracker which limits the scope of what needs to change as well as what we need to worry about losing control of.
[UPDATE 1/15/2016]: After the initial publication of this news, Brett Cannon let us know that he wrote up the entire history of the decision process behind Python moving to GitHub, providing a lot of interesting details and insights.
