New CPython workflow issues

As part of a discussion in 2014 about where to host some of the Python repositories, Brett Cannon was delegated the task of determining where they should end up. In early 2016, he decided that Python's code and other repositories (e.g. PEPs) should land at GitHub; at last year's language summit, he gave an overview of where things stood with a few repositories that had made the conversion. Since that time, the CPython repository has made the switch and he wanted to discuss some of the workflow issues surrounding that move at this year's summit.

He started by introducing himself as the "reason we are on GitHub"; "I'm sorry or I hope you're happy", he said with a chuckle. He wanted to focus the discussion on what's different in the workflow and what has been added (or will be) to try to make core developers more productive using the new workflow.

A bot to check whether a contributor has signed the Python contributor agreement (also known as the "CLA") was first up. Pull requests at GitHub are checked to ensure that the contributor has signed the form by "The Knights Who Say 'Ni!'", which labels the request based on the CLA status. It runs asynchronously and is not specifically tied to GitHub, Cannon said, so a switch to GitLab or elsewhere could be made some day if desired. There is also an "easter egg" in the bot regarding shrubbery, he noted.

It still takes one business day to process a newly signed CLA, so a contributor who has a pull request rejected because of the label is asked to wait that long and try again. Alternatively, any core developer can remove the CLA label, which will cause the bot to check again. There is an ongoing question about those who do not wish to agree to GitHub's terms of service, thus do not have a GitHub account. Some code contributed by a developer in that position was part of a pull request from another contributor, who credited the originator; the originator has not signed the CLA, however, so it is all in something of a "legal quagmire" at this point, Cannon said.

Another new bot is bedevere, which is meant to check pull requests for various kinds of problems. It currently checks to see if there is a reference to a bugs.python.org issue number in the title of the pull request and complains (with a reference to the Python Developer's Guide) if there is not. The issue numbers are now being placed into namespaces, in case the bug tracker changes down the road. So bedevere expects to find "bpo-NNNN" in the title (or "trivial").

The intent is to add more checks to bedevere to ensure the proper labels are present and that all of the status checks have passed for the pull request. Something that is not always being done for pull requests is to have reviewers approve changes made in response to their comments. Clicking to approve the changes is not a huge thing, he said, but it is handy and does get recorded by GitHub. In addition, references to previous pull requests should be done using the "GH-NNNN" namespace, which will still automatically link to the previous request, as the current "#NNNN" usage does. Checks for those kinds of things may be added as well.

Cannon then moved into the process to backport a pull request to an earlier version of Python. There are two different ways to do it, he said, either manually or the new, easier way. The manual way involves doing a "git cherry-pick" and then creating a pull request. The title of that request should have the branch target in it (e.g. "[3.6]") and the pull request ID from the original should be left in place. The "needs backport to X.Y" label should be removed from the pull request that was cherry-picked from.

The better way, though, is to use the cherry_picker tool that was recently written by Mariatta Wijaya. It automates most of the cherry-picking process. Developers just need to click one green button to create the pull request, then go remove the backport label from the original. The hope is that the label removal will be automated soon as well.

Plans

The goal of the GitHub switch has always been to make the workflow better, Cannon said, not just comparable to what was there before. The switch is now just three months old, which "feels like forever for me", so there are still some things to work through to make the workflow better than it was.

One area that has been problematic for some time is the maintenance of the Misc/NEWS file that contains small blurbs about changes made for a release. It is often the source of trivial, but annoying, merge conflicts, especially for backports. Moving forward, Larry Hastings has developed a blurb tool that will walk developers through the process of creating NEWS entries. Those entries will be stored as standalone files, with subdirectories for different sections of the file, and blurb can create the NEWS file on demand from this hierarchy.

There is a need for a bot to automate the backporting of pull requests based on the labels they contain. It could do the cherry-picking and create the pull request for each branch. Currently, he has four people who want to help work on the problem, so he needs to get them all working on the same code base. A more explicit link in pull requests to the bugs.python.org issue is desired as well. The current plan is to modify bedevere to add the link in the body of the pull request. He thinks that adding a message to each pull request for the link might get too noisy.

There has been some thought of automating the creation of the Misc/ACKS file, which lists all of the contributors to Python. He is not sure if anyone really cares about automating that, nor if it is particularly important, but it could perhaps be done. It could lead to the creation of something similar to thanks.rust-lang.org, he said. Grabbing the Git committer information from pull requests to go into ACKS would be a start.

Another thing that is needed is a way for reviewers to know when they should re-review a pull request. He suggested that bedevere could be changed to add a "[WIP]" (work in progress) tag to the request, which the contributor could remove when they are ready for review; they could also leave a comment that mentions the reviewer. But Guido van Rossum suggested doing it more like Phabricator, which he uses at Dropbox, does things: developers do not push their changes until they are ready for review. Others pointed out that may not work as code has to be pushed for the automated tests to run, so the developer may not know whether the code is ready until after they push. Cannon said that he had just begun to think about the problem, but it is clear that something is needed.

Another area that may need attention is a way to close stale pull requests. It is not a big problem yet, but may become one, he said. There could be a bot that measured the number of days since the last change and automatically close those that pass some threshold; the same should be done with those lacking a CLA signature. That code shouldn't really even be viewed until the CLA has been signed.

All are welcome to participate in the core-workflow project, Cannon said. There is an issue tracker on GitHub and a core-workflow mailing list that those interested should investigate.

Ned Deily asked if anyone had worked out a good strategy for dealing with GitHub email. As release manager, he would like to be able to see everything that is going on, which he used to be able to do, but is rather daunting for GitHub. There is someone working on an email bot, Cannon said, which may help. Barry Warsaw suggested sending all of the email to a mailing list that could be archived and put on Gmane, which Deily said would work as long as the threading was handled correctly.

Cannon ended the discussion by saying that he hopes to get to a point where the workflow is no longer the reason that core developers don't have the time to review pull requests. If folks simply don't have the time, that's one thing, but it should not be the workflow that holds them back. The CPython project currently has a delta of four additional pull requests every day and it would be great if the workflow improvements helped that number decline.

[I would like to thank the Linux Foundation for travel assistance to Portland for the summit.]