Home • Explore • Blog • CI
☰



rustc
4th chunk of `src/walkthrough.md`
a282216a6434b4e6f51bf09593709f80ee20c63c587d6d1d0000000100000848

The reviewer may request changes before they approve your PR, they may mark the PR with label 
"S-waiting-on-author" after leaving comments, this means that the PR is blocked on you to make 
some requested changes. When you finished iterating on the changes, you can mark the PR as 
`S-waiting-on-review` again by leaving a comment with `@rustbot ready`, this will remove the 
`S-waiting-on-author` label and add the `S-waiting-on-review` label.

Feel free to ask questions or discuss things you don't understand or disagree with. However,
recognize that the PR won't be merged unless someone on the Rust team approves
it. If a reviewer leave a comment like `r=me after fixing ...`, that means they approve the PR and 
you can merge it with comment with `@bors r=reviewer-github-id`(e.g. `@bors r=eddyb`) to merge it 
after fixing trivial issues. Note that `r=someone` requires permission and bors could say 
something like "🔑 Insufficient privileges..." when commenting `r=someone`. In that case, 
you have to ask the reviewer to revisit your PR.

When your reviewer approves the PR, it will go into a queue for yet another bot
called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches
the head of the `@bors` queue, `@bors` will test out the merge by running all
tests against your PR on GitHub Actions. This takes a lot of time to
finish. If all tests pass, the PR is merged and becomes part of the next
nightly compiler!

There are a couple of things that may happen for some PRs during the review process

- If the change is substantial enough, the reviewer may request an FCP on
  the PR. This gives all members of the appropriate team a chance to review the
  changes.
- If the change may cause breakage, the reviewer may request a [crater] run.
  This compiles the compiler with your changes and then attempts to compile all
  crates on crates.io with your modified compiler. This is a great smoke test
  to check if you introduced a change to compiler behavior that affects a large
  portion of the ecosystem.
- If the diff of your PR is large or the reviewer is busy, your PR may have
Title: PR Review Process: Responding to Feedback, Gaining Approval, and Merging via Bors
Summary
This section details the post-review process for PRs in the Rust project. It covers responding to reviewer feedback by marking the PR as 'waiting-on-review' when changes are complete. It also explains that PRs must be approved by a Rust team member before being merged and the process of merging with the help of the @bors bot once approved. Additionally, it mentions potential steps like FCP requests and crater runs for more substantial or potentially breaking changes.