Skip to content

Commit 88d955a

Browse files
committed
Update beta backport process.
1 parent d664dd1 commit 88d955a

File tree

1 file changed

+40
-30
lines changed

1 file changed

+40
-30
lines changed

src/release/backporting.md

Lines changed: 40 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -5,36 +5,46 @@ Only a few people are even aware of the process, but this is actually something
55

66
## Beta backporting in `rust-lang/rust`
77

8-
When somebody identifies a PR that should be backported to beta they tag it
9-
[`beta-nominated`](https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Aclosed+label%3Abeta-nominated).
10-
That means they want one of the teams to evaluate whether the patch should be
11-
backported. Also consider applying the `T-*` tag for a specific team, and the
12-
`I-*-nominated` tag for that team; that'll _really_ get their attention.
13-
Anybody with triage access is free to make these tags. Backports are mostly
14-
done to fix regressions. If the team thinks it should be backported they'll
15-
then additionally tag it
16-
[`beta-accepted`](https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Aclosed+label%3Abeta-accepted).
17-
18-
At that point the PR is ready to be backported. So the list of patches ready for
19-
a backport is those tagged
20-
[both `beta-nominated` and `beta-accepted`](https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3Abeta-accepted+is%3Aclosed+label%3Abeta-nominated).
21-
22-
So now somebody needs to go through those PR's and cherry-pick their commits to
23-
the beta branch. Those cherry-picks are then submitted as a PR _against the
24-
beta branch_, with a title started with `[beta]` (so reviewers can see its
25-
specialness). The OP of that PR should contain links to all the PRs being
26-
backported. [Here's an example](https://github.com/rust-lang/rust/pull/64097).
27-
Anybody can make these PRs!
28-
29-
After that a reviewer needs to verify that the backport looks correct, that it's
30-
submitted to the beta branch, and then approve via `@bors: r+`. Finally, they
31-
need to follow the links to the original PRs and _remove the `beta-nominated`
32-
tag_ (people forget to do this a lot). This last step indicates that the
33-
backport has been completed, so the `beta-nominated` and `beta-accepted` tags
34-
have three states.
35-
36-
If, on the other hand, a backport is declined the `beta-nominated` label is
37-
removed, closing the procedure.
8+
Backports of PRs to the beta branch are usually only done to fix regressions.
9+
Getting a PR backported to the beta branch involves the following process:
10+
11+
1. Add the label [`beta-nominated`](https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3Abeta-nominated) to the PR to be backported.
12+
This marks the PR as in the state that it needs attention from the appropriate team to decide if it should be backported.
13+
It is also suggested to apply the `I-*-nominated` and the appropriate `T-` (team) label: that'll _really_ get their attention!
14+
Anybody with triage access is free to make these labels.
15+
16+
2. If the team thinks it should be backported, then they should add the [`beta-accepted`](https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3Abeta-accepted) label.
17+
Otherwise they should remove the nominated label.
18+
19+
3. Occasionally someone will make a beta rollup PR.
20+
This is often done by the release team, but it can be done by anyone.
21+
The process here is:
22+
23+
1. Create a local branch off the `beta` branch.
24+
2. Cherry-pick all of the PRs that have both [`beta-nominated` and `beta-accepted`][nominated-plus-accepted] labels.
25+
3. (Recommended) Run some tests locally.
26+
It is not uncommon that the backports may not apply cleanly, or the UI tests need to be re-blessed if there are differences in the output.
27+
4. Open a PR **against the beta branch** with a title that starts with `[beta]` (so reviewers can see its specialness).
28+
5. List all of the PRs being backported in the PR description.
29+
[Here's an example](https://github.com/rust-lang/rust/pull/64097).
30+
31+
4. A reviewer (typically from the release team) needs to verify that the backport looks correct and that it's submitted to the beta branch.
32+
They will the approve with `@bors r+`.
33+
34+
5. Go through all of the PRs being backported and:
35+
36+
* Change the milestone to the correct value for the beta release.
37+
* Remove the `beta-nominated` label.
38+
This indicates that the backport has been completed.
39+
40+
If there are a lot of PRs, this can be done quickly by opening the [nominated + accepted][nominated-plus-accepted] query, check all the PRs being backported, and use the "Milestones" and "Label" drop-downs to modify multiple PRs in bulk.
41+
42+
In summary, there are three states that a PR can go through:
43+
1. `beta-nominated`: Needs the team's attention.
44+
2. `beta-nominated` + `beta-accepted`: Waiting to be backported.
45+
3. `beta-accepted`: Backport complete.
46+
47+
[nominated-plus-accepted]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Aclosed+label%3Abeta-accepted+label%3Abeta-nominated
3848

3949
## Stable backporting in `rust-lang/rust`
4050

0 commit comments

Comments
 (0)