decision: the per-unit TODO.md entry makes every merge invalidate every open PR #222
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Your convention is that a unit's
TODO.mdupdate rides in the same commit as the work, and every unit adds a bullet at the top of# Completed Steps. With one PR in flight that is free. With a dozen it is quadratic: each merge conflicts every other open PR on that one list, and each conflict costs a dispatched rebase, a freshmake check, and a force-push.Measured today: it is by far the largest single consumer of worker time in this milestone. #204 has now needed two rebases for nothing but this bullet — its substance passed review unchanged both times — and several other PRs have needed one each. The conflict is always the same trivial "keep both lines", and it is never interesting.
Nothing else about the convention is a problem. The entry itself is worth having; it is the placement — every unit writing to the same line of the same file — that serialises work that is otherwise independent.
Options
TODO.mdentry. The tracker is already authoritative for what landed, and each commit title ends(closes #N), sogit logreconstructs the same history exactly. I would write the Completed Steps summary once per milestone, at close, from the closed-issue list.Recommendation
(a). It removes the contention entirely rather than reducing it, loses no information, and the reconstruction at milestone close is more accurate than a dozen separately-authored bullets — those already vary in detail and phrasing depending on which worker wrote them. If you want the running log preserved between milestones, (b) is the cheaper compromise.
This is your convention and a workflow change, so it is your call. Nothing is blocked — I will keep dispatching rebases under (c) until you say otherwise.
Measured again today at higher concurrency, since the number is now much worse than when this was filed.
Four units landed this session. At this moment three PRs are cleared on the merits by independent review and blocked on nothing but this bullet: #201, #248, #249. Every one has
README.mdauto-merging cleanly andTODO.mdas the sole conflict.Two things that were not visible when this was filed:
make checkand e2e re-run. Concurrency in implementation does not buy concurrency in landing.TODO.mdcollision is what forces the rebase; the risk arrives with it.One further datum for option (b): the reviewer of #201 noted
# Completed Stepsis already no longer date-sorted, because "top of the list" and "newest" diverge once several units land in a day. So the ordering the current convention exists to preserve is not actually being preserved.Recommendation unchanged: (a). I am still running (c) and will keep doing so until you say otherwise — nothing is blocked on this, it is just costing roughly one dispatched worker per landing.