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

[Artem S. Tashkinov]

Hi Greg,

Let me try to restate the proposal more narrowly, because I think my 
previous wording mixed several related issues together.

I am not arguing that stable.git is not already continuous. It obviously 
is. Nor am I arguing that cutting a point release is expensive for 
upstream. I understand that from the stable maintainer side, tagging a 
release is cheap and well automated.

The problem is that the ecosystem still treats the x.y.z point release 
as the main externally visible consumption boundary, even though it is 
neither the real upstream unit nor the real downstream deployment unit.

The real upstream unit is the stable git branch: a linear sequence of 
accepted backports.

The real downstream deployment unit is a distro-built kernel package: 
base kernel, stable backports through some point in git history, distro 
patches/configuration, compiler/toolchain, signing, modules, CI, and 
user-visible packaging.

The x.y.z point release sits awkwardly in between. It is a useful 
compatibility marker for consumers that want that workflow, but it 
should not have to be the canonical boundary for everyone else.

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;
* 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;
* point releases may continue to exist for consumers that require them, 
but they become one possible checkpoint format rather than the central 
model.

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.

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?”

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:

```
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.

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.

So I am not asking to remove point releases from users that still need 
them. Keep them for conservative workflows, existing scripts, 
announcements, and consumers that require a simple named snapshot.

What I am arguing is that point releases should no longer be the 
privileged stable consumption model. The canonical model should be the 
signed stable git stream, with downstreams free to define their own 
tested integration points on that stream.

That would make the stable process match what it already is technically: 
a continuous sequence of accepted backports, not a sequence of magic 
tarball events.

Regards,
Artem