docs(release): name the expected DCO failure on a release cut - #640
Open
mocha06 wants to merge 1 commit into
Open
docs(release): name the expected DCO failure on a release cut#640mocha06 wants to merge 1 commit into
mocha06 wants to merge 1 commit 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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.