A fix the rules take for every line can still be wrong for one of
them, typically because it builds on code that line does not have.
The only ways to keep it out were backport/skip, which keeps it off
every line, and --defer, which holds it out of one batch: the next
batch tried it again, and a conflict that would never resolve came
back every run.
run --drop N --reason R records a drop in the line's record, bound to
the original's merge commit on main, and every later record carries
it, a new batch's included. What the open batch carries of a dropped
original comes off it the way --defer takes one off; any other drop
changes only the record, so a batch on a line that moved since stays
where it is. --undrop withdraws one. Both need an open batch, as every
write to the record does.
A drop comes after the rules and the carries: backport/skip, rules 2
to 4 or the line itself decide first and the drop stays on record,
and backport/include does not lift it. check notes a dropped original,
the body lists it, fold refuses it, and a record whose drop names
another original's merge stops every command. Each report keeps the
record's drops with the merge commit each is bound to and its reason,
held on read to the same rules, so an earlier report still says why
after an undrop.
A reason now travels from a body to terminals, bodies and comments, so
a reason or a file name in a record is believed only in the form a run
writes it, one clean line, and so is a report's diagnostic. Output
that repeats a reason, file names, a report ID or a state GitHub
reports escapes it.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
docs/release/backport-tasks/failed-ci.md says to defer the culprit with
run --defer --push. When the culprit was all the batch carried, the
push stopped with "close batch pull request #N instead", and closing
it by hand left nothing that said why: once closed, the deferred
original was simply missing.
The run now closes the batch itself, and does every write while the
pull request is open: the report, then the body, whose record keeps
the deferrals and says the batch is closing, at the head the rebuild
started from. The close and the deletion of the branch go only while
GitHub and the remote still show that head, and the deletion is
leased on it.
A close that stops part way is finished by the next run --push, before
anything else, and by no other command; a head the close did not
freeze is refused, never adopted. The run that finishes it stops
there, and fails when it was asked for --defer, since no open batch
is left to defer on. Recovery never writes the closed
pull request. A same-day batch that reuses the branch name and fails
to open its pull request leaves a branch the next run names for a
person to delete.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Each run rewrote the batch body whole, so the only account of what a
run found was gone at the next run, and a merged batch kept only its
last one. Nothing said what a classification was made of either: not
the heads it read, the policy, the tool or the flags.
A run now makes a report: every original merged into main since the
line branched, in exactly one category, with what the run read. Its
ID hashes the classification and names no pull request, so a new
batch's report is whole before GitHub numbers the pull request, and a
run that finds the same as the last one makes the same report, which
is posted once and keeps its first bytes. The body carries the latest
report under the record; a comment the tool never edits keeps each
one, so report reads any of them back, from merged batches too.
The comment goes up before the push and the body edit on an open
batch, and after the pull request a new batch opens with the report in
its body; a later run posts a report the body kept but no comment did,
byte for byte, before its own. Every write is preceded by a read of
the pull request, and nothing is written once it is merged or closed.
Both the comment and the body are rendered and measured before the
first write, so an oversized one stops the run with nothing written.
The record becomes version 2: what it was built from, with the run's
--no-workflow-files, which --defer keeps rather than resets, and the
report it goes with.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The deferrals a batch recorded were read only from the open batch pull
request. Once it merged, a conflict it had deferred showed as missing
and failed check and the cut, until some later run picked something
else and opened a new batch; a run that picked nothing opened none.
run, check, fold and notify now find the line's record in the newest
batch pull request whatever its state: one opened from a batch branch
of this repository by an author the batch trusts. A record that is in
doubt stops the command instead of letting it fall back to an older
one: a block by an author no longer trusted, a bot's batch whose block
was removed, a record that does not read whole, a closed record newer
than the open batch, or no record within the pages read.
The record is still written only to the open batch, and a merged or
closed batch is never written again, so a run that picks nothing with
no batch open keeps nothing and says so. The reader takes the version
2 record the next change writes; the writer stays at version 1.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
check --cut returned 0 whenever nothing was missing and nothing was
only on the batch, so a workflow original waiting for a maintainer
passed the cut once the pick beside it was labelled backport/skip or
reached the line by hand. The waiting original was not even printed:
the case that held it swallowed the warning the plain check gives.
check now sorts every original into one disposition and exits once,
so a wait fails the cut on its own. A backport/skip original the open
batch still carries is named with the run --defer that takes it out.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Backports were asked for pull request by pull request with labels and
opened by a bot, so whether a fix reached a release line depended on
someone remembering to ask, and the lines drifted apart. The policy
page states the rules instead: a fix or security fix merged into main
goes to every line the batch runs for, unless it is breaking, touches
platform migrations or a CRD, or changes the API in a way the API
review gate calls sizeable. Two labels let a maintainer override the
rules for one pull request.
The task pages give a maintainer the steps for a deferred conflict and
for a failed batch CI. The backports route in AGENTS.md, the
contributing and changelog guides and the PR template point at the
policy, and the commit format lists the security type the policy
takes.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
docs/release.md had grown into one page that mixed the release model,
the CI pipeline, changelogs, signatures, nightlies and the fires seen
at release time. A reader looking for one of them read all of it, and
an edit to one part reflowed the rest. It now indexes one page per
topic under docs/release/.
The pages already describe how fixes reach a release line through the
backport batch, which the following commits add. Workflows, scripts
and tests that named docs/release.md now point at the page that holds
the text they mean.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Myasnikov Daniil