Parents and children of check-in [06475f5aee]
|
2026-08-26
| ||
| 11:24 |
ops: read the history back — a route across days
The store recorded renders and nothing read them. The panels are one process's memory, so the page could say how fast a route is now and never whether it is worse than it was — which is the question after a deploy. The drilldown gains a per-day table from the store: p50, p95, max. Nearest-rank percentiles, matching how the snapshot computes them, so two numbers on one page both called p95 agree. Empty for no traffic and empty for history-off are different answers and the page gives the right one. closed check-in: a0fa952495 user: dmestas tags: landing-merge | |
| 11:19 |
Link a landing to the check-in it produced
settled_by names the reply that decided the state, not the commit, so this was assumed to need an upstream change. It does not: a merge check-in lists its primary parent first and the branches it merged after, so ord > 0 is the branch tip that landed, and the landing knows which branch it proposed. Structural, not a text or time heuristic. Resolves 18 of 18 accepted landings in this store. Bounded by when the landing OPENED, not when it was accepted: the merge lands before the artifact recording it is written. The landing page says what it landed as; a merge row on the timeline names the proposal and who approved it. Decorated, not collapsed — a merge is a real DAG node and hiding it would leave the graph drawing edges to a row the timeline does not show. check-in: 06475f5aee user: dmestas tags: landing-merge | |
| 10:05 | Accepted. A decision record and a discussion thread are different things, and the timeline now says which is which. check-in: 349027e507 user: dmestas tags: trunk | |