Repository navigation
decision(ci): what must be true of a branch before it may merge to Dev_new_gui — five issues, one settings change #15833
Description
Activity
- added sub-issues
on Sep 6, 2026 Duplicate pair: #15937 and #15833 describe one defect. Found during the v0.10.0 full-coverage triage (#17863), by reading bodies — a title-similarity pass over all 44,253 pairs in that milestone returned a maximum of 0.357 and found this pair, and five others, not at all.
Both address merges against a stale base, from two angles: #15937 enables the merge queue, #15833 offers
strict: trueas its option B. One defect, two candidate remedies — which makes them a single decision rather than two pieces of work. #15833 also lists #14500 in the same family.Evidence both resolve to: both are branch-protection / ruleset state rather than tree state, which is why both came back CANNOT VERIFY in the triage
Neither issue is being closed, deliberately. A duplicate pair is not a closure argument — closure needs the acceptance criteria checked per issue, which is a separate pass. In at least one of the six pairs only one member's work is actually done, so closing on duplication alone would close a live defect.
On the relationship type: GitHub's native "duplicate" marker requires closing the issue, so it is unavailable here. This comment creates a bidirectional cross-reference instead, which is a native timeline link discoverable from both issues rather than prose in a third place. If a hierarchy is wanted, a sub-issue link can be added where one member genuinely subsumes the other.
One decision, five issues
Five open issues are the same question wearing five faces, and none of them can be closed by a pull
request — the deliverable is a branch-protection change on
Dev_new_gui, not a diff. That is whythey have sat: an engineer picking any of them up writes code and discovers at the end that there was
none to write.
python-suite(12 shards) gates nothingstrict: false— a PR merges on checks computed against an older baseThe question
What must be true of a branch before it may merge into
Dev_new_gui?Current protection, measured today: 10 required contexts,
strict: false, 0 required approvingreviews,
required_conversation_resolution: true.Options
python-suiteto required contextsstrict: trueA and B and C are independent — any subset is coherent.
Recommendation
A now, B and C separately. A is the one with a measured cost we already pay: red tests have
merged to
Dev_new_guitwice (#13162's evidence), and the suite runs on every PR regardless, sorequiring it adds latency only when it is already failing. B's cost scales with open-PR count and is
worth revisiting when the queue is shorter. C is a workflow question rather than a correctness one.
What happens to the five
They become dependents of this decision. Whichever options are taken, each is closed by the settings
change plus a one-line note recording the new protection state — no code.