Comment out `change-id` in `config.example.toml`
This way, we only update CONFIG_CHANGE_HISTORY for major changes, which is much simpler (and updating example.toml doesn't make much sense)
r? `@Kobzol` (as this was mainly your idea)
This way, we only update CONFIG_CHANGE_HISTORY for major changes, which is
much simpler (and updating example.toml doesn't make much sense)
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Remove @JohnTitor from diagnostics pings
I've been inactive around diagnostics for a while so would like to remove myself from the diagnostics-related ping groups for now.
Allow setting `rla` labels via `rustbot`
https://github.com/rust-lang/rust-log-analyzer/pull/75 adds a `rla-silenced` label flag that will turn off RLA updates for non-bors tests. Allow setting that labels and others via `rustbot`.
Because bootstrap lib is already large and complicated, this should
make the "bumping change-id" process easier.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Revert "Remove TaKO8Ki from reviewers"
ref #116061
It's been a month since this pull request, and I now have some available time for reviews. Would it be okay to revisit it as a reviewer?
This reverts commit 8e06b25e39.
r? `@Nilstrieb`
Enable triagebot no-merges check
Follow-up on https://github.com/rust-lang/triagebot/pull/1704
### Motivation
Occasionally, a merge commit like cb5c011670 makes it past manual review and gets merged into master.
At one point, we tried adding a check to CI to prevent this from happening (https://github.com/rust-lang/rust/pull/105058), but that ended up [problematic](https://github.com/rust-lang/rust/pull/106319#issuecomment-1368144076) and was [reverted](https://github.com/rust-lang/rust/pull/106320). This kind of check is simply too fragile for CI, and there must be a way for a human to override the bot's decision.
The capability to detect and warn about merge commits has been present in triagebot for quite some time, but was never enabled at rust-lang/rust, possibly due to concerns about false positives on rollup and subtree sync PRs. This PR intends to alleviate those concerns.
### Configuration
This configuration will exclude rollup PRs and subtree sync PRs from merge commit detection, and it will post the default warning message and add the `has-merge-commits` and `S-waiting-on-author` labels when merge commits are detected on other PRs.
The eventual vision is to have bors refuse to merge if the `has-merge-commits` label is present. A reviewer can still force the merge by removing that label if they so wish.
### Note for contributors
The rollup tool should add that label automatically, but anyone performing subtree updates should begin including "subtree update" in the titles of those PRs, to avoid false positives.
r? infra
## Open Questions
1. This configuration uses the default message that's built into triagebot:
> There are merge commits (commits with multiple parents) in your changes. We have a [no merge policy](https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy) so these commits will need to be removed for this pull request to be merged.
>
> You can start a rebase with the following commands:
> ```shell-session
> $ # rebase
> $ git rebase -i master
> $ # delete any merge commits in the editor that appears
> $ git push --force-with-lease
> ```
Any changes to this are easy, I'll just have to add a `message` option. Should we mention the excluded titles in the message?
This configuration will exclude rollup PRs and subtree sync PRs from
merge commit detection. On other PRs, it will post the default warning
message and add the `has-merge-commits` and `S-waiting-on-author`
labels when merge commits are detected.
The eventual vision is to have bors refuse to merge if the
`has-merge-commits` label is present. A reviewer can still
force the merge by removing that label if they so wish.
Remove me from libcore review rotation
I'm looking at my commitments right now, and unfortunately this needs to go for at least a while.
If there's something in particular I can probably still take them, but I should drop out of the rotation for now.
bootstrap major change detection implementation
The use of `changelog-seen` and `bootstrap/CHANGELOG.md` has not been functional in any way for many years. We often do major/breaking changes but never update the changelog file or the `changelog-seen`. This is an alternative method for tracking major or breaking changes and informing developers when such changes occur.
Example output when bootstrap detects a major change:
Add `fmease` to rustdoc review rotations
`@fmease` asked me if it was okay for them to be part of the rustdoc review rotation. Since they are already reviewing a lot of rustdoc PRs, I think it's fine to add them to the rotation.
What do you think `@rust-lang/rustdoc` ?
r? rust-lang/rustdoc
