Remove references to homu, using rollup=never on rollups and queue resync

src/compiler/reviews.md

@@ -277,9 +277,7 @@ indicates that they approve the PR.
 People with bors privileges may also leave a `@bors r=username` command. This indicates that the
 PR was already approved by `@username`. This is commonly done after rebasing.
 
-Finally, in some cases, PRs can be "delegated" by writing `@bors delegate+` or
-`@bors delegate=username`. This will allow the PR author or the delegated user to approve the PR
-by issuing `@bors` commands like the ones above (but this privilege is limited to the single PR).
+Finally, in some cases, PRs can be "delegated" by writing `@bors delegate+`. This will allow the PR author or the delegated user to approve the PR by issuing `@bors` commands like the ones above (but this privilege is limited to the single PR).
 
 ### Reverts
 If a merged PR is found to have caused a meaningful unanticipated regression, the best policy is

src/infra/docs/bors.md

@@ -1,25 +1,15 @@
 # Bors
 
-The infrastructure team manages an instance of [Homu] called "Bors", to be used
+The infrastructure team manages a merge queue bot called ["Bors"][Bors], to be used
 for `rust-lang/rust`. The instance is available
 at [bors.rust-lang.org], and is backed by the [@bors] GitHub account.
 
 The service is configured [with Terraform][tf], and it's automatically deployed
-from the [rust-lang/homu] repository onto our [ECS cluster][ecs].
-
-## Maintenance procedures
-
-### Fixing inconsistencies in the queue
-
-Homu is quite buggy, and it might happen that the queue doesn't reflect the
-actual state in the repositories.
-
-See [Fixing inconsistencies in the bors queue](./bors/queue-resync.md) for
-instructions on how to do this properly.
+from the [rust-lang/bors] repository onto our [ECS cluster][ecs].
 
 [@bors]: https://github.com/bors
-[Homu]: https://github.com/rust-lang/homu
+[Bors]: https://github.com/rust-lang/bors
 [bors.rust-lang.org]: https://bors.rust-lang.org
 [ecs]: ./ecs-services.md
-[rust-lang/homu]: https://github.com/rust-lang/homu
+[rust-lang/bors]: https://github.com/rust-lang/bors
 [tf]: https://github.com/rust-lang/simpleinfra/tree/master/terraform/bors/

src/libs/maintaining-std.md

@@ -338,7 +338,7 @@ To try reduce noise in the docs from deprecated items, they should be moved to t
 [`rust-lang/rfcs`]: https://github.com/rust-lang/rfcs
 [`rust-lang/rust-forge`]: https://github.com/rust-lang/rust-forge
 [`rfcbot`]: https://github.com/rust-lang/rfcbot-rs
-[`bors`]: https://github.com/rust-lang/homu
+[`bors`]: https://github.com/rust-lang/bors
 [pr_assignment]: ../triagebot/pr-assignment.md
 [`crater`]: https://github.com/rust-lang/crater
 [`rust-timer`]: https://github.com/rust-lang-nursery/rustc-perf

src/release/index.md

@@ -5,7 +5,7 @@ support.
 
 ### External Links
 
-* The [Homu/Bors] page provides links to the pull request testing queues for the
+* The [Bors] page provides links to the pull request testing queues for the
   `rust-lang` GitHub organisation, as well as providing an overview of the bot's
   syntax you can use to interact with it.
 * [Rustup Component History] documents when a component was last available (if
@@ -17,5 +17,5 @@ support.
 
 [Rustup Component History]: https://rust-lang.github.io/rustup-components-history/index.html
 [PR Tracking]: https://rust-lang-nursery.github.io/rustc-pr-tracking/
-[Homu/Bors]: https://bors.rust-lang.org/
+[Bors]: https://bors.rust-lang.org/
 [`rustup-toolchain-install-master`]: https://github.com/kennytm/rustup-toolchain-install-master

src/release/process.md

@@ -84,7 +84,7 @@ going to finish soon (use your judgement here), you can "yield"
 priority to the stable release PR by going into that PR and typing this
 comment:
 
-> @bors retry
+> @bors yield
 > Yield priority to the stable release.
 
 ### `beta` PR

src/release/rollups.md

@@ -15,42 +15,41 @@ command accepts four values `always`, `maybe`, `iffy`, and `never`. See [the
 Rollups section] of the review policies for guidance on what these different
 statuses mean.
 
-You can see the list of rollup PRs on Rust's [Homu queue], they are
+You can see the list of rollup PRs on Rust's [Bors queue], they are
 listed at the bottom of the 'approved' queue with a priority of 'rollup' meaning
 they will not be merged by themselves until everything in front of them in the
 queue has been merged.
 
 ## Making a Rollup
 
-1. Using the interface on [Homu queue], select pull requests and then
-   use "rollup" button to make a rollup pull request. (The text about
+1. Using the interface on [Bors queue], select pull requests and then
+   use "Create rollup" button to make a rollup pull request. (The text about
    fairness can be ignored.)
-   **Important note**:  consider for addition PRs marked as
+   **Important note**: consider for addition PRs marked as
    `rollup=always`, `rollup=maybe` and `rollup=iffy`, based on the
    review policies of [the Rollups section].  Be extra careful when
    deciding what to include, in particular on `rollup=maybe` and
    `rollup=iffy` PRs. We should try as much as possible to avoid risking
-   and hit regressions (bugs or perf).  Also consider that contributors
+   and hit regressions (bugs or perf). Also consider that contributors
    often forget to tag things with rollup=never, when they should have
    done so, so when PRs are not explicitly tagged with rollup, be extra
    careful.
 
 2. Run the following command in the pull request thread:
 
     ```console
-    @bors r+ rollup=never p=5
+    @bors r+ p=5
     ```
 
 3. If the rollup fails, use the logs rust-log-analyzer
-   provides to bisect the failure to a specific PR and do
-   `@bors r-`. If the PR is running, you need to do `@bors r- retry`. Otherwise,
-   your rollup succeeded. If it did, proceed to the next rollup (every now and
-   then let `rollup=never` and toolstate PRs progress).
-4. Recreate the rollup without the offending PR starting again from **1.**. There's a link in the rollup PR's body to automatically prefill the rollup UI with the existing PRs (minus any PRs that have been `r-`d)
+   provides to bisect the failure to a specific PR and unapprove it with
+   `@bors r-`. Then close the rollup PR, and recreate it without the offending PR starting again from **1.** There's a link in the rollup PR's body to automatically prefill the rollup UI with the existing PRs (minus any PRs that have been `r-`d). See more information in [Failed rollups](#failed-rollups).
+4. If the rollup succeeds, you can proceed to the next rollup (every now and
+   then let `rollup=never` PRs progress).
 
 ## Selecting Pull Requests
 
-The queue is sorted by rollup status. In general, a good rollup includes one or two `iffy` PRs (if available), a bunch of `maybe` (unmarked) PRs, and a large pile of `always` PRs. A rollup should never include `rollup=never` PRs.
+The queue is sorted by rollup status. In general, a good rollup includes one or two `iffy` PRs (if available), a bunch of `maybe` (unmarked) PRs, and a large pile of `always` PRs. A rollup should never include `rollup=never` PRs (bors makes sure of that).
 
 The actual absolute size of the rollup can depend based on experience, people new to making rollups might start with including 1 `iffy`, 4 `maybe`s, and 5 `always`s, but more experienced people might even make a rollup of 1-2 `iffy`s, 8 `maybe`s, and 10 `always`s! Massive rollups are rarely needed, but as your intuition grows you'll get better at judging risk when including PRs in a rollup.
 
@@ -85,5 +84,5 @@ or confirm your hypothesis.
 If a rollup continues to fail you can run the `@bors rollup=never` command to
 never rollup the PR in question.
 
-[Homu queue]: https://bors.rust-lang.org/queue/rust
+[Bors queue]: https://bors.rust-lang.org/queue/rust
 [the Rollups section]: ../compiler/reviews.md#rollups

src/release/triage-procedure.md

@@ -50,7 +50,7 @@ not need a review yet.)
 [s-experimental]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AS-experimental+sort%3Aupdated-asc
 [no-status-tags]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Aopen+-label%3AS-waiting-on-author+-label%3AS-waiting-on-review+-label%3AS-waiting-on-team+-label%3AS-waiting-on-bors+-label%3AS-waiting-on-crater+-label%3AS-waiting-on-bikeshed+-label%3AS-waiting-on-perf+-label%3AS-blocked+-label%3AS-inactive+-label%3AS-waiting-on-fcp+-label%3AS-waiting-on-ACP+-label%3AS-experimental
 [crater]: https://github.com/rust-lang-nursery/crater
-[bors]: https://github.com/rust-lang/homu
+[bors]: https://github.com/rust-lang/bors
 
 ### Procedure