In the last month there have been 3 accidents where WebRTC developers pressed "Revert" on a Gerrit CL which is already a revert, and had their relands instantly merged, bypassing all checks. But, none of them expected that to happen, and in most cases they had to also re-revert them immediately.

Some things that I think should never happen:

* Adding "No-Tree-Checks: true, No-Try: true" and also "Automatically send revert change to CQ" without any confirmation.
* Adding "No-Tree-Checks: true, No-Try: true" to a reland.
* Adding "No-Presubmit: true", EVER.


In https://chromium.googlesource.com/infra/gerrit-plugins/chromium-behavior
there is already logic to detect reverts. The first easy thing to do would be to not add those scary tags if it's a nested revert.

And I quite dislike relands done through the "Revert" button in general, they contain too much noise compared to a "Reland". Would be nice to steer people away from that.
 

In the last month there have been 3 accidents where WebRTC developers pressed "Revert" on a Gerrit CL which is already a revert, and had their relands instantly merged, bypassing all checks. But, none of them expected that to happen, and in most cases they had to also re-revert them immediately.

Some things that I think should never happen:

* Adding "No-Tree-Checks: true, No-Try: true" and also "Automatically send revert change to CQ" without any confirmation.
* Adding "No-Tree-Checks: true, No-Try: true" to a reland.
* Adding "No-Presubmit: true", EVER.


In https://chromium.googlesource.com/infra/gerrit-plugins/chromium-behavior
there is already logic to detect nested reverts as relands. The first easy thing to do would be to not add those scary tags if it is such a nested revert.

And I quite dislike relands done through the "Revert" button in general, they contain too much noise compared to a "Reland". Would be nice to steer people away from that.