We don't want to block changes like doc changes on a broken builder.
Sometimes the reason for trybot failures are known (e.g. linux-blah-blah as a full disk, request out to buildbot owner to fix) and need to be ignored.
But maybe someone that can override a -2 is enough. Not sure.

Can you point to examples of merges that had trybot failures? I don't want to single people out, but it may be instructive to look at what the trybot failures were like.

Two recent examples that have failed trybots results:

https://go-review.googlesource.com/c/go/+/221603 cmd/compile/internal/syntax: faster and simpler source reader
https://go-review.googlesource.com/c/go/+/222241 Revert "cmd/compile/internal/syntax: faster and simpler source reader" (although this was ultimately abandoned in favour of a root cause fix).

And:
https://go-review.googlesource.com/c/go/+/222978 misc/spectre: add spectre index test
https://go-review.googlesource.com/c/go/+/223378 Revert "misc/spectre: add spectre index test"

Those two examples were both modified after the trybots failed.
If anything, those examples would argue that the rule should be that trybots must be run on the latest patch before submission is allowed.
Although I guess the rule proposed by the OP and by me have a lot of overlap. Either would have caught those two examples. My rule would catch in addition CLs which never got a trybot run.

Those two examples were both modified after the trybots failed.
If anything, those examples would argue that the rule should be that trybots must be run on the latest patch before submission is allowed.
Although I guess the rule proposed by the OP and by me have a lot of overlap. Either would have caught those two examples. My rule would catch in addition CLs which never got a trybot run.

I didn't mean to be overly prescriptive in my suggestion. It was intended just to highlight that there appears to be a workflow problem where trybots errors /appear/ to be being overlooked or not revalidated after a patchset update.

I would suggest considering something that blocks on failure by default but is easily overridden when needed.

Sometimes the reason for trybot failures are known (e.g. linux-blah-blah as a full disk, request out to buildbot owner to fix) and need to be ignored.

The TryBots generally all run on fresh VMs, so that's not usually an issue.

That said, it's also handy to be able to submit after fixing a couple of typos or comments and only re-building locally (to make sure the typo-fix didn't also introduce a stray edit elsewhere), without waiting on another TryBot run. (For example, see https://golang.org/cl/222277: I submitted PS16, which had the same code as the TryBot+1 PS14 but a few comment and commit-message changes.)

https://golang.org/cl/143023 was another recent example of a change with a TryBot -1 and subsequent break (the revert in https://golang.org/cl/220237 was abandoned after a trivial fix in https://golang.org/cl/220277 was submitted).

I notice that Gerrit has started to prompt when I hit the Submit button with unresolved comment threads.

Perhaps it could do the same for changes that lack a TryBot +1?

TryBot failures are now unresolved comments, which cause a prompt when trying to submit but do not completely block it the way a -2 would. That seems like the right balance to me.

Does anyone object to closing this issue?

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group