You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/release/backporting.md
+5-4Lines changed: 5 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -8,10 +8,9 @@ Only a few people are even aware of the process, but this is actually something
8
8
Backports of PRs to the beta branch are usually only done to fix regressions.
9
9
Getting a PR backported to the beta branch involves the following process:
10
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.
11
+
1. Add the label [`beta-nominated`](https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3Abeta-nominated+-label%3Abeta-accepted) to the PR to be backported.
12
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.
13
+
Anybody with triage access is free to add this label.
15
14
16
15
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
16
Otherwise they should remove the nominated label.
@@ -22,14 +21,16 @@ Getting a PR backported to the beta branch involves the following process:
22
21
23
22
1. Create a local branch off the `beta` branch.
24
23
2. Cherry-pick all of the PRs that have both [`beta-nominated` and `beta-accepted`][nominated-plus-accepted] labels.
24
+
It is usually preferred to not include PRs that have not been merged in case there are any last minute changes, or it fails when running the full CI tests.
25
25
3. (Recommended) Run some tests locally.
26
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
27
4. Open a PR **against the beta branch** with a title that starts with `[beta]` (so reviewers can see its specialness).
28
28
5. List all of the PRs being backported in the PR description.
29
29
[Here's an example](https://github.com/rust-lang/rust/pull/64097).
30
30
31
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+`.
32
+
They will then approve with `@bors r+ rollup=never` (to avoid it being rolled up on accident).
33
+
If the author of the PR has r+ rights, and has not made significant changes while backporting, they can also self-approve the PR.
33
34
34
35
5. Go through all of the PRs being backported and:
0 commit comments