There's a steady trickle of patches that need to be ported to the beta and stable branch. Only a few people are even aware of the process, but this is actually something anybody can do.

Beta backporting in rust-lang/rust

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. It is also suggested 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-accepted.

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 approve via @bors: r+. 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.

If, on the other hand, a backport is declined the beta-nominated label is removed, closing the procedure.

Stable backporting in rust-lang/rust

Backports to the stable branch work exactly the same as beta ones, labels have just a slightly different name: stable-nominated identifies a PR to be discussed for a backport and stable-accepted is a PR accepted for backport. Declined stable nomination will have the stable-nominated label removed.

The T-release will decide on a case by case basis if a stable backport will warrant a point (.patch) release (f.e. release a 1.50.1 between 1.50 and 1.51).

Beta Backporting in rust-lang/cargo

The procedure for backporting fixes to Cargo is similar but slightly more extended than the rust-lang/rust repo's procedure. Currently there aren't backport tags in the Cargo repository, but you'll initiate the backport process by commenting on an associated PR, requesting a backport. Once a Cargo team member has approved the backport to happen you're good to start sending PRs!

  • First you'll send a PR to the rust-1.21.0 branch of Cargo (replace 1.21 with the current rustc beta version number). Like with rust-lang/rust you'll prefix the title of your PR with [beta] and ensure it's flagged as going to beta.

  • Next a Cargo reviewer will @bors: r+ the PR and put it into the queue. Eventually bors will automatically merge the PR (when tests are passing) to the appropriate Cargo branch.

  • Finally you'll send a PR to the rust-lang/rust repository's beta branch, updating the Cargo submodule. The Cargo submodule should be updated to the tip of the rust-1.21.0 branch (the branch your Cargo PR was merged to). As like before, ensure you've got [beta] in the PR title.

After that's all said and done the Cargo change is ready to get scheduled onto the beta release!