The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Artem S. Tashkinov" <aros@gmx.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	stable@vger.kernel.org
Subject: Re: [RFC/PROPOSAL] Shifting the x.y.z Stable Tree to a Continuous, Signed Patch-Stream Model
Date: Sun, 14 Jun 2026 13:19:32 +0200	[thread overview]
Message-ID: <2026061420-emote-resend-9ad0@gregkh> (raw)
In-Reply-To: <5f62925e-0faf-40aa-a594-10ef6d50f24e@gmx.com>

On Sun, Jun 14, 2026 at 08:16:06AM +0000, Artem S. Tashkinov wrote:
> 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.

Not true at all, I would argue that this is the ONLY real deployment
unit as things are NOT tested in the stable releases except on that
boundry.  We do not do full testing on each individual commit, only at
the release points.  So to assume that you can consume a portion of the
stable release feed is not correct at all.

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

Nope, sorry, unless you want to run all tests on each individual point,
this isn't going to change.

Also, you failed to answer my previous questions, like who is "we" that
is having problems with the current release process that is so difficult
to consume as-is?

thanks,

greg k-h

      parent reply	other threads:[~2026-06-14 11:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-24  9:38 [RFC/PROPOSAL] Shifting the x.y.z Stable Tree to a Continuous, Signed Patch-Stream Model Artem S. Tashkinov
2026-05-24 10:56 ` Greg Kroah-Hartman
2026-05-25  0:33   ` Theodore Tso
2026-06-14  7:49   ` Artem S. Tashkinov
2026-06-14  8:16   ` Artem S. Tashkinov
2026-06-14  9:33     ` Willy Tarreau
2026-06-14 11:19     ` Greg Kroah-Hartman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026061420-emote-resend-9ad0@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=aros@gmx.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox