Re: [RFC/PROPOSAL] Shifting the x.y.z Stable Tree to a Continuous, Signed Patch-Stream Model

[Willy Tarreau]

On Sun, Jun 14, 2026 at 08:16:06AM +0000, Artem S. Tashkinov wrote:
> A better model, in my view, would be:
> 
> * stable.git remains the canonical source of truth;
> * every downstream-consumable stable state is identified by branch + signed
> commit ID, optionally with a signed machine-readable manifest;

Well, you have stable-queue which is getting closer to that.

> * distros consume `v7.0 + stable commits through <commit>` or `linux-7.0.y
> as of <date/commit>`, according to their own testing and release policy;

what makes you think that distros will want to pick even less tested
or validated commits ? Right now we know that some distros cherry-pick
just what they see fit and they miss important fixes, probably based on
lack of trust of a well-exposed set of patches that compose a version.
If you refine the granularity, there will be even less trust in the
level of test of each commit and they might wait even longer to pick
fixes at all.

> * point releases may continue to exist for consumers that require them, but
> they become one possible checkpoint format rather than the central model.

This model at least gives a good indication of how late your system is
(the last number roughly corresponds to the number of weeks past the
release). It also offers opportunities to maintainers to voice in
saying "not this patch" or "pick that one with it" even if it does
not happen that often. And it increases the exposure on patches
combinations to more users. The finer your granulary, the less tested
each combination is. Here the current model sets discrete points in
time where many users deploy the same version hence the same set of
patches. This is particularly important and it has allowed many times
in the past to quickly spot a regression that would have taken much
longer to be noticed if everyone would deploy at a different point.
> 
> This decouples two decisions that are currently conflated:
> 
> 1. upstream's decision that a commit belongs in the stable branch;
> 2. a downstream's decision that a particular aggregate is ready to ship to
> its users.
> 
> Those are not the same decision. Fedora, Arch, Debian, Ubuntu, enterprise
> vendors, embedded vendors, and live-patching teams all have different risk
> tolerances, hardware exposure, CI capacity, reboot policies, module/signing
> workflows, and urgency. A single upstream x.y.z cadence cannot be the right
> integration boundary for all of them.

I see it the opposite way: those who don't want to follow stable branches
already don't wait for patches to land into -stable to have them, and
those who follow it will have even less reasons to trust aggregates on
which they have no feedback at all.

> In the recent 7.0 security/regression mess, the useful downstream question
> should not have been "which point release has Greg cut yet?" It should have
> been "which stable commits are required for the complete fix set, and has
> our actual distro kernel artifact built from that stable commit range passed
> enough testing to ship?"

So in fact you're just proposing to move the testing more on the distro
side hence to fragment it.

> If distros routinely consumed the stable branch as a signed linear stream,
> they could pin a specific stable commit, build from it, test it, and declare
> exactly what they shipped:

Given that nothing prevents them from doing this already, surely if they
don't do it it's because it's an extra effort that doesn't solve any
problem ?

> ```
> base: v7.0
> stable branch: linux-7.0.y
> stable commit: <hash>
> included range: v7.0..<hash>
> downstream patches/reverts: <list>
> ```
> 
> That is more auditable than chasing point releases or cherry-picking
> individual commits from intermediate states. It also makes clear that the
> distro package, not the upstream tarball, is the object that was actually
> tested and deployed.

That's already the case, usually they have different version numbering.

> There is also a practical artifact problem here. For long-lived stable
> series, publishing a complete source tarball for every x.y.z release is very
> wasteful. By 5.10.258, the 5.10.y series has hundreds of distinct tarballs,
> each over 100 MB compressed, representing tens of gigabytes of mostly
> duplicated source snapshots for one stable line. The real information is the
> base tree plus the incremental stable deltas. Git already represents that
> naturally.

That's an orthogonal aspect. Some tools are happy with the immediate
availability of these tarballs, and if they are ever considered wasteful,
they will probably stop being produced/archived or they might be deleted
after some time. But many users just download incremental patches.

All of this sounds very strange to me personally, more like a solution
looking for a problem.

Willy