Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sun, 2024-07-14 at 08:31 -0400, Sasha Levin wrote:
> Hi folks,
> 
> The Linux kernel community relies heavily on commit tags to identify
> and manage patches destined for stable kernel branches. Currently, we
> use a "Stable tag" (cc: stable@kernel.org) to indicate that a patch
> should be included in stable kernel branches, and a "Fixes tag"
> (Fixes: 012345678901 ("commit subject")) to point to an older commit
> that the new commit fixes or improves. However, this scheme has led
> to some unintended consequences.
> 
> One of the main issues is that most Fixes-tagged commits (>80%) end
> up in a stable tree, leading some authors to omit the Stable tag
> altogether. This means we may not be trying hard enough to include
> critical commits in stable kernel branches. On the other hand, some
> authors are unhappy when commits without a Stable tag end up in a
> stable kernel branch. To address these shortcomings, I propose
> introducing an "Improves tag" (Improves: 012345678901 ("commit
> subject")) and altering the meaning of the Fixes tag.

I've got to say this looks like a bad idea: your complaint is we're not
being clear enough about the cc:stable and fixes semantics, so the
proposal is to introduce a tag with even less clear semantics in the
hope that it will somehow improve the situation. Why not simply be much
more crisp about the meaning of Fixes and no cc:stable? If everyone
realised that Fixes without cc:stable meant the patch wouldn't be
included in a stable tree that surely gives all the semantics you need
without having to get everyone to try do differentiate between a fix
and an improvement?

One of the big reasons patches get Fixes without cc:stable is simply
that it's an -rc fix for a merge window regression (so no released
kernel has it in and therefore no stable kernel needs it), so you'd
also need to explain that case in the improve docs (because it's a
genuine fix, just not a stable candidate).

So the clear rules look like they should be

   1. every patch fixing something should have a fixes tag pointing to
      the fixed commit
   2. Only patches with cc:stable should go automatically in to stable
      trees and as far back as the fixes tag allows
   3. if a patch without cc:stable is later discovered to be a required
      fix, people can ask for it to be backported.

James