release gate: train-aware placement - never block mid-train; hard-block only a fresh train starting over threshold #217

Closed
opened 2026-07-17 16:32:37 +00:00 by hexajon · 0 comments
hexajon commented 2026-07-17 16:32:37 +00:00 (Migrated from codeberg.org)

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:

  • releasable count >= the hard threshold, AND
  • no merge landed on the default branch within the preceding grace window (proposed: 60 minutes).

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:

  • Finish with releasable >= hard threshold and a default-branch merge < grace window ago: proceeds, with a release-due warning line.
  • Finish with releasable >= hard threshold and no recent merge: blocked with the current message.
  • Grace window configurable in one place (script constant), default 60m; covered by the release-gate script tests (fixture repo with crafted commit times).
  • Companion weighting change (#218 if filed together) composes: the threshold this rule consults is whatever the score-based trigger defines.
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: - releasable count >= the hard threshold, AND - no merge landed on the default branch within the preceding grace window (proposed: 60 minutes). 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: - Finish with releasable >= hard threshold and a default-branch merge < grace window ago: proceeds, with a release-due warning line. - Finish with releasable >= hard threshold and no recent merge: blocked with the current message. - Grace window configurable in one place (script constant), default 60m; covered by the release-gate script tests (fixture repo with crafted commit times). - Companion weighting change (#218 if filed together) composes: the threshold this rule consults is whatever the score-based trigger defines.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
sixfold-space/madtea#217
No description provided.