[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240405025439.GC13376@mit.edu>
Date: Thu, 4 Apr 2024 22:54:39 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Greg KH <gregkh@...uxfoundation.org>, Tejun Heo <tj@...nel.org>,
Sasha Levin <sashal@...nel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Do we need a "DoNotBackPort" tag?
On Thu, Apr 04, 2024 at 05:56:58PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>
> I know, as I wrote that (as you likely remember). ;-) But it seems it's
> not well known; and maybe making it explicit that this can be used to
> convey a "DoNotBackport" message is supported as well.
>
> Guess I'll prepare a patch to do that then and we'll see how it goes
> from there.
Maybe something like "ManualBackportOnly"instead? The basic idea is
that it's not that the commit should *never* be backported, but only
with human intervention where someone has specifically requested the
backport, perhaps with qualification test.
(For example, the XFS file system has an implicit ManualBackportOnly
on all commits, and the XFS stable maintainers are responsible for
backporting identifying commits with Fixes: tags, and running QA
before passing on a request to having them be backported.)
- Ted
P.S. I'd love to be able do something equivalent for ext4, if we
could scare up the resources to do the same, in terms of having some
company fund the necessary developer resources, or someone turn up to
volunteer to do that for ext4. Gentle reader, if that's you or your
company --- let's talk. :-)
Powered by blists - more mailing lists