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
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.
0 commit comments