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

[Artem S. Tashkinov]

Hi all,

The relentless cadence of critical vulnerability disclosures and public 
exploits over the past month—including Copy Fail (CVE-2026-31431), Dirty 
Frag (CVE-2026-43284/500), Fragnesia (CVE-2026-46300), and the ptrace 
exit race (CVE-2026-46333)—has highlighted a severe structural 
bottleneck in how we package and distribute stable backports.

When fatal logic flaws or memory corruptions strike core subsystems, our 
current point-release model fractures. Spinning up whole new point 
releases (7.0.4, 7.0.5, 7.0.7) in a matter of days just to address 
incomplete fixes, subsystem regressions, or independent public 
disclosures (such as the recent GRO managed-frag UAF exploit dropped 
directly to GitHub gists by researchers) creates massive administrative 
fatigue for maintainers and downstream teams alike.

Upstream has long maintained that the stable tree is effectively a 
continuous stream of fixes, and that users should track the tip of the 
stable branch rather than cherry-picking. It is time our release 
infrastructure matches this reality.

### The Proposal

I propose transitioning the stable tree (`linux-x.y.y`) away from 
manual,discrete point-release tarballs (`x.y.z`). Instead, we should 
treat the stable sub-version purely as an append-only, continuous, 
git-native patch stream.

Major releases (e.g., 7.0, 7.1) remain the foundational code boundaries, 
but sub-versions are eliminated as monolithic manual artifacts.

### The Implementation: How It Works

To ensure downstream distributions, enterprise compliance engines, and 
automated testing rings can still securely ingest code, we can replace 
the manual tarball with a decoupled, automated asset pipeline:

1. **The Git-First Stream:** The stable branch (`linux-7.0.y`) remains 
the single source of truth. Commits are pushed as soon as they pass 
stable criteria and automated sanity testing.

2. **The Signed Patch-Stream Archive:** Instead of packaging the entire 
30M+ line source code tree into a new tarball for every quick fix, 
upstream infrastructure maintains a rolling, cumulative patch sequence 
for the major cycle:

linux-7.0-stable.series = \sum (patch_1 + patch_2 + ... + patch_n)

Every time a fix is merged to the stable branch, the patch is appended 
to a publicly accessible, cryptographically signed manifest file
(`linux-7.0-stable-patches.tar.bz2` or a standard `series` file) 
alongside a detached signature.

3. **Automated Snapshot Tags:** If the industry strictly requires an 
immutable archive for compliance, point-release numbers can be replaced 
by automated, time-stamped git tags and machine-generated source 
snapshots cut on a strict, automated interval (e.g., every 48 hours), 
removing human maintainers entirely from the release timing.

### Why This Benefits the Ecosystem

* **Eliminates Churn and Latency:**

When a patch introduces an edge-case regression or requires an immediate 
follow-up (a common reason for rapid point-release sequences), 
maintainers do not need to coordinate a whole new release event. The 
follow-up fix is simply patch $n+1$. Downstream CI pipelines ingest it 
natively via standard git fetches.

* **Maintains Git-Native Debugging:**

Debugging stable regressions via `git bisect` has always been 
patch-based, not release-based. Since point releases are meant strictly 
for backported bug fixes, removing the arbitrary `x.y.z` release tags 
changes nothing about a developer's ability to isolate a regression. If 
anything, it prevents downstream vendors from pulling out-of-order 
patches that complicate bisection across distros.

* **Eases Downstream Automation:**

Modern tracking distributions (Arch, Fedora snapshotting, etc.) can 
switch to trunk-based intake, automatically building from the signed tip.

For enterprise distributions (RHEL, Ubuntu LTS) where constant kernel 
packaging and reboots are untenable, a fluid patch stream allows vendor 
security teams to more rapidly feed live-patching infrastructure 
(`kpatch`, `kgraft`), applying critical CVE fixes directly to runtime 
memory without changing the base package version.

* **Bridges the Compliance Gap:**

Embedded, automotive, or medical compliance pipelines
that legally require a static, verifiable code artifact can validate 
their software against the base major release tarball ($7.0.0$) plus the 
cryptographically signed, append-only stable patch series manifest.

The manual compilation, testing, and cutting of sub-version tarballs is 
an administrative artifact of the late 1990s. Shifting to an explicit, 
signed patch-stream architecture acknowledges the velocity of modern 
vulnerability research, strips away artificial latency, and frees our 
stable maintainers to focus on code quality rather than release 
management overhead.

I would love to hear thoughts, architectural blockers, or feedback from 
the stable maintainers and distribution teams on the feasibility of this 
transition.

Best regards,
Artem S. Tashkinov