I'm parked on you

Pick an option on each card and press Done; your answer goes straight back to the session. The raiser's pick is marked. "I'm not sure" is a real answer.

1Should a PR need the reviewer's verdict on its latest push before it can enter the merge queue, with a backstop that pulls it out if a red verdict lands later? (#17614)

In plain terms. Want PRs to wait for the code reviewer before they can merge, plus an automatic pull-back if a reviewer blocks one that's already lined up? Today one merged with a blocker because nothing waited for the reviewer.

Both: require verdict + red backstopthe raiser's pick Require verdict only Leave as is I'm not sure — go find out

Why, and what was tried

The session raising this recommends: Both: require verdict + red backstop
#17513 merged today with a blocking review because nothing required one: main's only required check is Nested Gate, which checks the nested packages and never reads the review. Requiring the verdict closes the hole; the backstop catches a red that lands while a PR is already queued. Both are workflow or ruleset edits under the dangerous-diff rule, so they need your OK.
Tried first, unsuccessfully: Verified on GitHub: the 'Require CI' ruleset requires only Nested Gate. On head 8b045b5 Nested Gate passed 19:07:21Z (a real job, nested packages only), review started 19:09:26Z and failed 19:13:06Z, and the PR merged 19:21:36Z. Inside the queue, review passes automatically by design. Trinity found the gap and I confirmed it. This replaces b91416348, which had a typo (#17514) and the wrong root cause.

f598bd05 is parked on this.

Answered and withdrawn (1)

b91416348 A PR got merged even though the code reviewer flagged a blocker a few minutes after it was queued. Want CI to yank it back out in that case, and wait for the reviewer before queuing? — withdrawn

Pick an option above, then press Done.