Python's GitHub migration and workflow changes

Brett Cannon gave an update on the migration of Python's repositories to GitHub and the associated workflow changes at the 2016 Python Language Summit. The goal is modernize the development process; right now that process is "old school", which is "good or bad depending on who you ask". After looking at the options, GitHub seemed to be the best choice for housing the repositories; PEP 512 lays out the options and rationale for those interested. LWN looked at some of the discussion surrounding the move back in December 2014.

The starting point is to move some simple repositories first: devinabox (a tool to get CPython developers everything they need easily), benchmarks (which may be getting a fresh start, so it might not need to migrate), PEPs (there is already an unofficial GitHub repository), and the Developer's Guide (which just needs changes so it can be built from a Git clone).

The main reasons to start with simpler repositories is to ease the transition. People who are already familiar with Git and GitHub will find it easier to contribute, while the maintainers of those projects will get push-button merging of pull requests. It will move the bugs out of the main bugs.python.org tracker into project-specific bug trackers, as well. There will also be a "CLA bot" to track whether contributors have signed the Python Contributor Agreement by matching GitHub usernames to signers of that document.

So far, the CLA bot is running and the devinabox repository has been moved. The PEPs repository is next. Cannon had hoped that the unofficial repository was up to date, but that turned out not be true. So there will need to be a migration, but "it shouldn't be too big of a deal".

But then there is the "363kg repo", which is the one for CPython. He wants to try to determine what must be in place before that repository can be migrated. The goal is to be able to handle contributions more quickly, with the hope that leads to more core developers—and "rainbows everywhere". The longer it takes to make the switch, while staying with the current workflow, the harder it will be, he said.

The question is: "what do you have to have before moving CPython to GitHub?" He has identified some definite requirements, including decisions that need to be made on the mechanics of using Git and GitHub. Whether pull requests should be merged using squash commits and how to handle merging across branches are two of those decisions. The sys._mercurial attribute (which provides information on the Mercurial commit ID that the CPython interpreter was built from) will need to be replaced. The Developer's Guide will need to be updated, but it will be on GitHub at that point, so a branch can be started to make those changes.

There is also a set of possible requirements that he has assembled. Whether or not they are truly needed before the CPython switch to GitHub can happen is up to the core developers, Cannon said. How to handle the misc/News file, which carries little blurbs about features and changes in the release, needs to be determined. If each contributor changes it on their branch, that will just lead to merge conflicts. It could be handled automatically by deriving the entry from the commit message or that file could be split up into individual-entry files and reassembled at release time. But, he said, there may be no real need to block moving to GitHub until a solution for that is found.

Another possible requirement is linking between GitHub and bugs.python.org. That is important to have, but may not be needed before the switch. It comes down to a question of whether he needs to solve these problems before switching or whether the developers can live with some manual parts of the process until these kinds of things are resolved. He encouraged the developers to think about and discuss the real requirements over the coming months.

The "moonshot goal" of this effort is to not have any pull requests that languish for long periods of time. He would like to have things automated to the extent that developers aren't burdened. That way, they could review patches monthly—or even weekly—which would go a long way toward reducing the patch-review queue.