docs(release): name the expected DCO failure on a release cut - #640
docs(release): name the expected DCO failure on a release cut#640mocha06 wants to merge 3 commits into
Conversation
The back-merge section already described a squash-rewritten author, but only as something that happens to back-merges. A `dev -> main` release pull request carries the same commits and fails the same way, and nothing said so. The release-PR section now names it where a reader first meets it, and the back-merge bullet covers any later pull request that carries the history rather than back-merges alone. The bullet also stops saying the commit lands on `main`: most such commits are squashed onto `dev`. Also records the trap: a cut whose DCO is green because it carries almost nothing was made from the wrong branch, and the notes it stamps will be missing what `dev` holds. Signed-off-by: mocha06 <52426811+mocha06@users.noreply.github.com>
adriannoes
left a comment
adriannoes
left a comment
There was a problem hiding this comment.
Reviewed at 53b29caa: static review of RELEASE.md plus DCO check-run records for the last release cut and back-merge. No worktree, no live MCP.
Verdict: needs changes into dev.
Required before merge
- The back-merge DCO bullet now pairs a back-merge with a
devintomainrelease cut as equivalent expected-red events. Those git ranges are complementary. The last cycle was red on the cut and green on the back-merge. See the thread onRELEASE.md:165.
Decisions I would make
- The Notes still call #639 pending as the reason to skip
CHANGELOG.md. #639 closed unmerged after #641 stamped currentdev. I would rebase ontoorigin/devand either add a short Unreleased docs bullet or restate the skip as a docs-clarification choice. This does not block merge.
What worked well
- The new paragraph before the bump steps puts the release-cut DCO expectation where a releaser looks first. The green-tiny trap is the right reading of recutting off a short branch.
- Saying the mismatch can land on
mainordev, not only the default branch, matches how feature pull requests squash ontodev.
Review path
Tier lite, trust trusted, reviewed at 723313ff1f20b3d23d960071a8d5af4c45d87a9d...53b29caa830030d96728f0acc7fd6d3b2c75e0c4.
| Gate | Result |
|---|---|
| CI on head | green (lint, test, DCO, Shell scripts, install.sh then uninstall.sh) |
| DCO trailer on this commit | pass |
| Worktree / unit tests | n/a (lite) |
| Live smoke | n/a (docs-only) |
| DCO-bullet refute | survives (3 verification Attempts reproduced) |
| Judge | GPT Extra High; blocking finding kept IMPORTANT |
Not covered: executing release-pr or opening a live cut. The DCO claim was checked against check-runs on #638, #639, and #626 plus the frozen backmerge.py / release.py body generators.
…-dco-expectation Signed-off-by: mocha06 <52426811+mocha06@users.noreply.github.com>
Answers the review on RELEASE.md:165. A back-merge and a `dev -> main` release cut scan complementary ranges, so they cannot carry the same squash-rewritten commit: #638 was red on 47 of them, #639 green because those commits were already on `dev`. The bullet is back-merge only again, and now says a back-merge that follows a release carries the release commits alone and is green, so a green one does not read as a surprise. The offender-list sentence stays a back-merge fact: `dco_mismatches()` lives in backmerge.py, and release.py has no DCO handling at all. The paragraph above the bump steps is unchanged — it already states the release-cut expectation in the complementary direction. Adds the CHANGELOG entry the earlier body said it was skipping. That reason was a conflict with the pending back-merge; #639 closed unmerged and `## [Unreleased]` on dev is live again. Signed-off-by: mocha06 <52426811+mocha06@users.noreply.github.com>
|
The blocking finding is answered in the On the The branch is level with |
adriannoes
left a comment
adriannoes
left a comment
There was a problem hiding this comment.
Reviewed at 2c11fc7, after 53b29caa.
The blocking DCO bullet is back-merge only. Its heading now says red when that range carries the mismatched commit. A back-merge that follows a release is described as green, because those commits are already on dev. The offender-list sentence stays in the back-merge bullet. The release-cut paragraph above the bump steps is unchanged. CHANGELOG.md gained an Unreleased bullet for this docs change.
Re-checked at this tip: the three Done when items on RELEASE.md:165 hold. CI is green (lint, test, DCO, Shell scripts, install.sh then uninstall.sh, skill frontmatter). The two new commits carry matching Signed-off-by trailers.
Verdict: merge-ready into dev.
2 participants
Motivation
RELEASE.mddescribed the squash-rewritten author only as something that happens to back-merge pull requests. Adev → mainrelease cut carries the same commits and fails DCO the same way, and nothing said so.The failure is easy to misread as a fault in the release commit, and the obvious "fix" makes things worse: re-cutting from somewhere with less history turns the check green by carrying almost nothing, which is also a cut that stamps none of
dev's notes.The bullet was also inaccurate on where such a commit lands. It said
mainand "the default branch", but most feature pull requests squash ontodev, which is where the mismatched commits actually accumulate.Outcome
The
dev → mainrelease PR section states the expectation where a reader first meets it, points at the mechanism instead of repeating it, and records the trap about a suspiciously green check.The back-merge bullet now covers any later pull request that carries the history — a back-merge and a release cut alike — and says the commit is unrepairable once it is on
mainordevrather than on the default branch alone.Notes
No
CHANGELOG.mdentry.## [Unreleased]ondevis where thev0.5.0-beta.1notes still sit unstamped, and the pending back-merge (#639) inserts the## [0.5.0-beta.1]heading directly above them. An entry added here would land inside the released section and conflict with that merge. It is a documentation clarification with no behavior change.