release gate: train-aware placement - never block mid-train; hard-block only a fresh train starting over threshold #217
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea#217
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Today the >= 20-releasable hard gate in the finish path fired in the middle of a six-branch merge train: four branches merged, then the fifth was refused until a release was cut, splitting a batch that had been reviewed and sequenced as a unit. The gate did its job (bounded divergence, and the release was genuinely due) but its placement made the interruption arbitrary - the train was going to finish within the hour either way.
Decided mechanism (stateless, git-derived): the hard gate blocks a finish only when BOTH hold:
A train in motion (recent merges) gets to complete even across the threshold; the next train starting while over threshold is blocked at its FIRST finish, which is the natural boundary the gate always meant to guard. The gate message keeps the current wording plus one line saying the train-grace rule when it applies.
Acceptance criteria: