Review of #393: rollouts run one at a time today (issue 525); Approve on Telegram (issue 953 for the terminal); 976's place in the order; milestone 1 takes the rest of 525 and acceptance test 9

2026-10-17 00:06:59 +02:00
parent 75d3ac0f82
commit 748641dd22
3 changed files with 7 additions and 6 deletions
@@ -140,7 +140,8 @@ never into the running one, unless it blocks the running one.
 5. **The reviewer marks each pull request ready as soon as the acceptance is shown** with
   `mesh-delivery.mark-ready` (the delivery of the head it approved, who reviewed it and why), which writes the
   label `mesh/ready` and then `ready at <full sha>`, the order the forge counts (issue 913); mesh-delivery merges it when its checks pass
-   and the operator approved the merge into main on Telegram or at the terminal (ADR 0364, ADR 0398 §3). Beyond that
+   and the operator approved the merge into main on Telegram, the channel that proves who answered today (ADR 0364,
+   ADR 0398 §3; an Approve at the terminal is issue 953). Beyond that
   Approve, the operator's word is waited for only when the step changes what the operator sees, removes
   data, or needs a step only the operator's terminal can take; the lead says which before the step starts.

@@ -49,8 +49,8 @@ by milestone. Until 2026-10-16 this document described the predecessor's pipelin
  cut at once (ADR 0282 §2, as ADR 0304 §1 changed it). The batch and its merges are rows in the controller's
  store, cut by a timer every 5 s, with a catch-up timer every 5 minutes for merges no batch holds.
 - **The rollout.** A closed batch becomes one rollout, at most one commit per repository, tiered along the module
-  graph. Rollouts that share no repository, module or graph edge run side by side; overlapping ones wait (ADR 0282
-  §3, ADR 0304). A rollout's builds go to every machine at once, with no first-machine gate, and the rollout ends on
+  graph. Rollouts run one at a time: a batch cut while a rollout is open is queued behind it, whatever it shares
+  with it. Running unrelated rollouts side by side (ADR 0282 §3, ADR 0304 §2) is decided and not built (issue 525). A rollout's builds go to every machine at once, with no first-machine gate, and the rollout ends on
  the machines' reports or after fifteen minutes of silence (ADR 0360). A controller timer advances rollouts every
  30 s.
 - **A merge during a rollout.** Its place in the next batch is a store row the open rollout's holder writes. On
@@ -490,14 +490,14 @@ when the previous one's delivery is done. Milestones 5 and 6 are split into step

 | # | Outcome | Acceptance tests | Repositories | Issues |
 |---|---|---|---|---|
-| 1 | A merge during a running delivery is never dropped and needs no person's release; the merge window lives on the bus | 8, 11 | mesh-controller | 973 |
+| 1 | A merge during a running delivery is never dropped and needs no person's release; the merge window lives on the bus; a rollout that shares nothing with an open one runs beside it | 8, 9, 11 | mesh-controller | 973 (with the rest of 525) |
 | 2 | A ready mark is acted on within seconds, and each pull request has at most one waiting check | 5, 6, 7 | mesh-controller, mesh-catalog (mesh-delivery, gitea) | 974, 975, 976 |
-| 3 | A feature with a new seat verb across the controller and the catalogue is delivered as one group: no `after:` line, one composed check, no "release branches" | 1, 9 | mesh-controller, mesh-catalog (mesh-delivery) | 977, 978 |
+| 3 | A feature with a new seat verb across the controller and the catalogue is delivered as one group: no `after:` line, one composed check, no "release branches" | 1 | mesh-controller, mesh-catalog (mesh-delivery) | 977, 978 |
 | 4 | A delivery backs up the data it moves first, and a failed backup holds it and is said | 3 | mesh-controller, mesh-catalog (mesh-delivery, the backup seat's holder) | 980 |
 | 5 | One read of a module on a node names the commit, build and rollout that put it there | 10, 12 | mesh-controller, mesh-catalog (mesh-config, nats) | 981 |
 | 6 | Builds use installed toolchains with no container, builders fetch over SSH with their own key, and an SDK change ships in one group with its users | 2, 4 | mesh-catalog (build modules, build-agent, ssh-client, gitea), mesh-controller, mesh-sdk | 979, 971 |

-The issues are linked `depends-on` in this order.
+The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971.

 ## What is not decided here