Mirror rust-lang/rust review labels, enable triagebot shortcuts and review-changes-since functionality#6773
Merged
Merged
Conversation
ytmimi
approved these changes
Jan 20, 2026
ytmimi
left a comment
ytmimi
left a comment
Contributor
There was a problem hiding this comment.
I think adding more automation and keeping things consistent with r-l/rust is a good idea
And configure triagebot review status label flipping.
Instead of
`pr-{not-reviewed,waiting-on-author,follow-up-review-pending}`, for two
reasons:
1. Consistency with `rust-lang/rust`. The `S-*` status labels are the
ones that `rust-lang/rust` uses.
2. I don't think the `not-reviewed` vs `follow-up-review-pending`
distinction makes a lot of difference in practice. However, we can
still keep the `pr-follow-up-review-pending` label, since that is
previously manually applied anyway.
Through `@rustbot label`.
Basically, a web-rendered version of `range-diff` to make review after force-pushes easier.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Review labels
Currently,
rustfmtseems to use a set of manually maintained (flipped) labels:This is inconsistent with whatStatus: awaiting some action (such as code changes or more information) from the author.
,
S-waiting-on-review
Status: awaiting review from the assignee but also interested parties.
,
S-blocked
Status: blocked on rustc, an RFC, impl work, etc.; please also add a block reason label
} that
rust-lang/rustuses, and the PR states tends to also mismatch the status of the label at the moment. This PR proposes that we switch over to the same set of binary labels { S-waiting-on-authorrust-lang/rustuses, and enabletriagebot's automation to help to automatically flip the labels (e.g. flipping toS-waiting-on-authorwhen reviewer pressed Request Changes).I don't think the pr-not-reviewed vs pr-follow-up-review-pending distinction makes a lot of difference in practice. However, we can still keep the pr-follow-up-review-pending label, since that is previously manually applied anyway.
See also
shortcutsbelow.shortcutsSee https://forge.rust-lang.org/triagebot/shortcuts.html:
Basically, convenience method for toggling between the PR states { S-waiting-on-authorStatus: awaiting some action (such as code changes or more information) from the author.
,
S-waiting-on-review
Status: awaiting review from the assignee but also interested parties.
,
S-blocked
Status: blocked on rustc, an RFC, impl work, etc.; please also add a block reason label
} even when the user does not have write access to this repo (so cannot use label UI):
review-changes-sinceSee https://forge.rust-lang.org/triagebot/review-changes-since.html:
I.e. a rendered page of
range-diffso that the reviewer don't need to do it locally.