feat(series): Carry patch/ entries onto the buffer as part of porting

[krlmlr]

A patch/ entry does nothing on -dev. vendor-one.sh applies the buffer's stack to every tree it regenerates, so <S>-build is where an entry has to live to affect what the series vendors next.

Entries reach -dev two ways and only one of them puts them there. A firing writing one during a repair is told by stage 3 to commit it onto the buffer in the same firing — that half works. But stage 4's port brings whole main commits over, patch/ files included, so an entry born as a pull request against main arrives on every -dev without any firing deciding to put it there, and reaches no buffer at all, -build taking no ports by design.

The drift is quiet while upstream leaves the patched file alone, because the buffer is then internally consistent and its commits carry no delta for that file. It bites the first time upstream touches one: the buffer regenerates that file without the fix, and the commit that reaches -dev from it reverts the fix while reading as an ordinary vendor commit.

What this changes

Carry it where the port already runs, rather than detecting the gap afterwards. series-port.sh --apply now finishes by calling the new series-patch-sync.sh <S> --apply, which is a read-only report on its own.

What carries is decided by test-applying against the buffer's own tree, never by the file list — a buffer runs ahead of main, so an entry main needs may not fit the engine the buffer has vendored, and committing it there regardless breaks the next vendor run outright rather than helping anything:

• carry — applies cleanly, taken with its effect on the tree
• satisfied — reverse-applies, so the effect is already there; the entry is taken alone, to keep the two stacks identical
• stale — neither: upstream moved the code out from under it, so on this engine the entry answers nothing

Two shapes are reported and never carried, because both are judgement and both break the next vendor run if guessed at:

• a supersession — a candidate whose files an entry the buffer has and -dev lacks also touches. 0003-Fix-clang-warnings-in-re2 displacing 0003-Try-to-ignore-clang-warnings is the standing example: the real fix, hoisting and naming the anonymous struct, replacing the two #pragma clang diagnostic ignored lines that stood in for it.
• an entry main edited in place, which the port brings to -dev under a name the buffer already has. Candidates are therefore compared by blob; a name-only comparison calls those two stacks level. 0009-Remove-stderr-for-zstd is that one today.

series-check.sh gains a PATCH DRIFT line per series, printed beside the verdict like CUTOVER is, naming what the two stacks differ by in all three directions. It is the backstop, not the mechanism: after a port, what it reports is precisely what the carry declined, which is stage 3 work.

Finally, two entries born on a series buffer are routed to main, which is where the loop says a fix belongs when it is not series-specific: 0034-Guard-explicit-producer-token-in-concurrent-queue and 0035-Silence-deprecated-Catalog-GetEntry-self-delegation. Both apply cleanly to main's vendored tree today, and both keep the names the buffers already use, so the stacks match rather than growing a third spelling of the same diff.

Measured, not assumed

Every entry in the union of the stacks was test-applied, reverse-applied and neither, against every buffer and every -dev. That is what separated the four cases above, and it caught one that a file-list carry would have got wrong: 0036-Mark-two-assert-only-bindings-used and 0038-Initialize-every-member-of-DependencySubject are on main, and on the main series' newer engine they fit nothing. Committing them to that buffer would have failed its next vendor run with vendor.sh's "patches moved" exit.

The three entries born on a buffer that do not appear in the routing commit — 0036-Guard-assert-only-plan-verifiers, 0037-Cast-to-void-in-the-default-aggregate-state-memset and 0039-Return-past-the-exhaustive-DatePart-specifier-switches — do not apply to main's engine at all, so they stay series-specific by engine version and reach main when main's engine reaches the code they answer.

Effect on the branches

Run against all six series, the carry closed the drift on the four that had it (main, main-fwd, v1.5-variegata, v1.5-variegata-fwd; the two v1.4-andium series are frozen, take no ports, and were already level). The 0003 supersession was then resolved by hand as stage 3 work, reversing the entry being replaced and applying the replacement, with src/duckdb/third_party/re2 verified byte-identical to each -dev afterwards.

What remains is stale only, and correctly so. No -dev branch was touched: buffers carry no CI, so closing all of this cost no check runs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D36f3J68XGNUAu4o1DX5xD