@pablogsal recently opened a PR for automating revert commits.
I agree with the issue but respectfully disagree with that particular proposal.

Copying the reasoning from Pablo's comment:

[There should be automation that will] open (but doesn't merge) revert PRs when a builtbot builder has failed [...].

The idea is not to force the revert on people because a human still needs to merge the PR and the discussion needs to happen as well but to start the process in a way that's not someone opening a revert PR to someone else (it's a bot opening the revert PR).

This won't caught everything but it will caught as many things we can be sure that are caused by a single commit and the PRs will be open by a bot and not a human, highlighting that this is an automated process to not have the CI broken.

The problem that this solves is not having the CI red for a long time making fixes or reverts more challenging as time passes and the reverts are not clean anymore. We have discussed many times (not only in this last core dev sprint) that having the buildbot failing for a long time makes things much more difficult, specially when issues start to pile up and people are slow to act..

My own plan of action would be to allow humans to initiate the process:

• Teach cherry-picker to --revert commits. (Note that in Git, cherry-picks and reverts are very similar once started, see the --continue option for cherry_pick and revert.)
• Teach @miss-islington to open a revert PR, and re-open the issue, when a new needs-revert label is added. The GitHub comment should explain that we revert because failing CI can hide other issues.
• Then, have Buildbot automation apply the label, so that a human isn't initiating the action.

Does that sound reasonable?

(FWIW, my current priority is putting breaking PRs, and individual test failures, on the dashboard -- the first step for a revert or fix is for the failure to show up there.)