ADR 0279: a wontfix duplicate lets go only with its original; ready said once per spell; a delivery not asked is loud (review)

2026-10-10 17:54:48 +02:00
parent 3e346e7cd7
commit 6b718eeca3
2 changed files with 11 additions and 8 deletions
@@ -55,8 +55,8 @@ check of ADR 0278 is one of its parts.
   the operator asked for "delivered first".
 2. **When every issue it depends on is resolved, or closed as wontfix, and every pull request its fix names is
   delivered** — the delivery's own state, not the merge. Chosen. A wontfix dependency will never be delivered,
-   and an issue must not wait for it for ever; a duplicate's original is linked by its own `duplicates` link and
-   carries the work.
+   and an issue must not wait for it for ever — except one closed as the duplicate of another: the work moved
+   there, so it lets go only when its original does.

 ### How the tracker learns a fix is delivered

@@ -100,15 +100,18 @@ consolidated schema exist for this store; a reader that does not know a key igno
 ### 3. Ready

 An issue is **ready** when it is not resolved or wontfix and every issue it depends on is either wontfix, or
-resolved with every pull request its `fixed-by` names (`<repository>#<number>`) delivered; an entry that names no
-pull request, such as a commit, is not waited for. An issue with no dependency is ready. When a dependency's fix
+resolved with every pull request its `fixed-by` names (`<repository>#<number>`, in any case, or the forge's page of
+it) delivered; an entry that names no pull request, such as a commit, is not waited for. A wontfix dependency
+closed as the duplicate of another counts as its original does. Readiness is said once per spell: an issue keeps
+the dependencies it was said ready for, so one delivery letting two of them go says it once. An issue with no dependency is ready. When a dependency's fix
 is delivered and that makes an issue ready, the issue gains a note saying so and naming the dependency, and the
 tracker says the event **`ready`** with its number, so a picker can react.

 The tracker consumes `mesh-delivery.transition`; a transition to `delivered` with a pull request's number marks
 every issue whose `fixed-by` names `<repository>#<number>`. On its own `moved` to `resolved`, it asks
-`mesh-delivery.checks` for each pull request in `fixed-by` it has not heard delivered, and marks those whose
-delivery is `delivered`.
+`mesh-delivery.checks` for each pull request in `fixed-by` it has not heard delivered, at most three per handling,
+and marks those whose delivery is `delivered`. An ask that fails, or more left to ask, has the event offered again,
+so a delivery never asked ends in `max-deliveries` rather than in silence.

 ### 4. Triage

@@ -228,8 +228,8 @@ what it depends on, and the issue is said ready when every fix it waits for is d
  **Needs**: none, decision (a decision record first), operator (the operator's answer is required).
 - **`depends-on`**: refused when it would close a cycle; `get` shows what an issue depends on and what it is
  needed by.
- **Ready**: not resolved or wontfix, and every dependency wontfix, or resolved with every pull request its
-  `fixed-by` names delivered. The tracker consumes `mesh-delivery.transition` and, at its own `moved` to resolved, asks
+- **Ready**: not resolved or wontfix, and every dependency wontfix (one closed as a duplicate counts as its
+  original), or resolved with every pull request its `fixed-by` names delivered; said once per spell. The tracker consumes `mesh-delivery.transition` and, at its own `moved` to resolved, asks
  `mesh-delivery.checks` for what it has not heard; an issue made ready gains a note and the event `ready`.
 - `open` takes severity and needs; `set` changes severity, needs and suggested owner; `list` filters on severity,
  needs and ready. `groom` triages the backlog, dry run first.