Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

[Jiri Kosina <jikos@kernel.org>]

On Fri, 19 Jul 2024, Vegard Nossum wrote:

> With my distro hat on, I definitely think Fixes: should be used for
> anything that fixes a bug, regardless of whether it was a bug introduced
> with a new feature or it was a regression.
> 
> Fixes: is incredibly useful in the following way: You can check whether
> you need to apply/cherry-pick a patch simply by checking whether you
> have the commit it fixes (or a backport of it) in your branch. As a
> distro (or even as a user), if you have a buggy commit in your branch
> and there's a known fix for it, you almost always want the fix.
> 
> I don't really like the "Cc: stable # version+" tag for the exact same
> reason: Authors/maintainers may be looking at when the bug was
> introduced and decide not to put that "Cc: stable" tag since the patch
> that introduced the problem was in an earlier -rc of the same release or
> never appeared in a stable kernel _at that point in time_. But that's
> the wrong approach, as the fixed commit may be backported to stable (or
> a distro kernel) many years after it was merged into mainline (just look
> at all the commits with Stable-dep-of: in stable), and without the
> Fixes: tag we have no way to know that the fixed commit has a bug and
> needs to have subsequent patches applied.

For me, the biggest question coming out of this discussion is: what are 
the groups / types of patches that should be getting "Cc: stable" despite 
not being fixes for some older code?

As "fixing bugs" should be all what the stable tree is supposed to be 
about, shouldn't it? (*)

One of the obvious categories is "fixing HW issue", being it either 
mitigations for HW security issues, or adding new device IDs, adding 
quirks, etc.

But what next?



(*) There is this famous defition at the beginning of

	Documentation/process/stable-kernel-rules.rst

but I guess it's obvious to everybody that it doesn't apply.

-- 
Jiri Kosina
SUSE Labs