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" and "Take it to the engineering bridge" are real answers.
1Should the pre-queue type check become a REQUIRED check in merge ruleset 14925316 (blocks merging when absent or errored), or stay as now: stamped on every arm from every machine, fail-open?
In plain terms. The quick type check now runs on every PR, from both machines. Should it also be a hard rule that blocks merging whenever it fails, even when the check itself breaks?
Why, and what was tried
The session raising this recommends: Keep as is 2 of 362 batches in 24h were type errors, 0 from Fede; a hard rule blocks on the check's own breakage (~1 in 67 runs, never passes on lockfile PRs) and reverses ADR-0043. Tried first, unsuccessfully: Decider f04ab7601 ruled the reading of 'make it required for all' and the ruleset edit belong to an attended human; f43044670 and ff6060309 escalated the remaining human steps.
eb5eac84 is parked on this.
Answered and withdrawn (15)
b90970611 The merge line is jammed because it tries to test 24 PRs at once on too few machines; can I cut that to 6 so things start landing again? — withdrawn
b90984875 A fix that stops unrelated changes from colliding on one shared list of unused scripts is ready, but a safety rule holds it because one of its 676 one-line comments lands in a permissions script. Yes lets it merge; hold keeps the old shared list, which caused 64 collisions last month. — withdrawn
b90985597 The admin-page safety test kept 25 hand-typed totals that unrelated changes had to edit and that clashed (52 edits in a month). A reviewed fix deletes those totals but keeps every per-page login check. Yes merges it and lets later fixes of the same kind merge without asking; hold keeps the totals. — answered: Yes, merge it; same rule for later derived-count deletions
b90987803 Big pull requests skip a whole set of must-run safety tests before they reach the merge line (51% of PR test runs last evening). A one-line reviewed fix makes that set run on every PR, adding about 4 minutes to big PRs only. It's held because it edits the CI config. Yes merges it; hold keeps big PRs skipping those tests. — withdrawn
b90988368 Two reviewed fixes make PRs run safety tests they currently skip until the merge line: big PRs skip the must-run set (half of PR runs), and 'bookkeeping' tests are filtered out of every PR (36 merge-line failures). Each is a one-line change to the CI config, and that config edit is why both are held. Yes merges both; hold keeps those tests merge-line-only. — folded into b91001954
b90999081 When a change fails in the merge line, it is often put straight back in with nothing fixed, fails again at the front, and throws away everything queued behind it. That happened 58 times in about 40 hours, costing up to 189 of 3,079 runs. A reviewed fix pulls such a change back out until someone pushes a fix. Yes turns it on; hold keeps today's behavior. — withdrawn
b91001954 Four reviewed fixes are held only because they touch files that need an attended person to read before merging: the unused-scripts cleanup (one comment line lands in a permissions script), a one-line reviewer-instructions update, and two one-line CI-config changes that make PRs run safety tests they currently skip. Yes merges all four; you can also pick which. — answered: Yes: merge all four
b91002065 The merge line tests 6 changes at once. Measured overnight: at 6, daytime demand (26 changes an hour) outran it (15 merged an hour, changes waited about 2 hours). In the 2 hours it was at 10, the backlog cleared at 24 an hour. Going above 10 adds nothing. Raising to 10 costs about 18% more machine time per merge. Yes sets it to 10. — withdrawn
b91003943 When a change fails in the merge line, GitHub's 'merge when green' usually stays on and puts it back about 12 minutes later with nothing fixed. It then fails again and throws away everything queued behind it: 58 times in about 40 hours, up to 189 of 3,079 runs. The reviewed fix switches 'merge when green' off on a failed-check removal, and pulls a change back out if it re-enters with no new commit. Yes turns it on. — answered: Yes: failed changes wait for a fix (Gera in the #agent-smith thread via Smith, 2026-10-03 06:35Z: "Also drive the known fix as well." — authorised building and driving it)
b91026508 Three merged-line PRs (#15994, #15996, #15997) make four self-tests read their safety check's exception list instead of keeping their own copy. That ends the hand-sync that broke main this morning. We later found #15520 had already closed that breakage path. Sharing the list also removes a deliberate second edit, a two-key, that some of these files documented as on purpose. They are in the merge line and will land before you read this; per the queue rule I did not pull them. Keep them and fix the wording, or revert the four? — answered: Keep, fix wording
b91064871 Session eb5eac84 is frozen on a prompt in its terminal (tmux pane %393) that Smith will not answer. Deciding here records your choice on the block; the keystroke itself still has to happen at the pane — nothing will type into a live menu on your behalf. — withdrawn
b91072566 When a PR is too big, its own tests are currently skipped entirely on the PR (44% of PR runs last week ran zero tests), so its broken tests are first caught in the merge line, taking innocent changes down with them. #16060 makes a big PR still run its own changed tests and the tests that import its changed code, up to 200 files. It's approved and green; only its dangerous-diff label holds it, because it edits ci.yml. Lift it? — answered: Yes: big PRs test their own changes
b91397490 When a batch of PRs is being tested together it now takes a bit over 30 minutes, and GitHub gives up at exactly 30 and throws the PRs out even when they passed. Should we give it 45 minutes instead? — answered: 60 min
b91397536 Before a PR gets in line to merge, Gera's merge command runs a quick type check, but Fede's side skips it, and those skipped ones cause about a third of the failed test batches. Should Fede's side run the same quick check? — answered: Yes, add it
b91405137 The check that stops shell scripts from silently ignoring failures keeps one central list of exempt scripts, and that shared list makes unrelated changes collide. #15873 moves each exemption into its own script, as one comment line. Review also caught a hole in the first version: two scripts could swap exemptions unnoticed. That's fixed, and now any new exemption must also raise a limit in the same change. Approved at ec4b7aef. It's held only by the dangerous-diff label, because one of the 18 scripts is a permissions helper and the only change there is a comment. Main has moved since, so it'll be caught up once when you're ready to lift. Lift it? — answered: I'm not sure — go find out