Hi again. Today I want to tell you about this little corner of the project process that needs more attention: beta backports.
There’s a steady trickle of patches that need to be ported to the beta branch. Only a few people are even aware of the process, but this is actually something anybody can do. Here’s how it works:
When somebody identifies a PR that should be backported to beta they tag it beta-nominated. That means they want one of the teams to evaluate whether the patch should be backported. I also suggest applying the I-nominated and and a T- (team) tag as appropriate: that’ll really get their attention. Anybody with triage access is free to make these tags. Backports are mostly done to fix regressions. If the team thinks it should be backported they’ll then additionally tag it beta-accpted.
At that point the PR is ready to be backported. So the list of patches ready for a backport is those tagged both beta-nominated and beta-accepted.
So now somebody needs to go through those PR’s and cherry-pick their commits to the beta branch. Those cherry-picks are then submitted as a PR against the beta branch, with a title started with beta (so reviewers can see its specialness). The OP of that PR should contain links to all the PRs being backported. Here’s an example. Anybody can make these PRs!
After that a reviewer needs to verify that the backport looks correct, that it’s submitted to the beta branch, and then hit the merge button. Finally, they need to follow the links to the original PRs and remove the beta-nominated tag (people forget to do this a lot). This last step indicates that the backport has been completed, so the beta-nominated and beta-accepted tags have three states.