Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

[Sasha Levin <sashal@kernel.org>]

On Sun, Jul 14, 2024 at 09:35:26AM -0400, James Bottomley wrote:
>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

What does it mean exactly? What should we be doing now that wasn't
happening before?

All our documentation explicitly says that a stable tag is a *must*,
we've been nagging folks to add it when they haven't, and we give them
the spiel whenever we're asked why a certain fixes-only commit didn't
make it into the stable trees.

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

By your logic folks already have to do it now, right? The decision
around whether to add a stable tag or not means that there needs to be a
decision around whether something is a fix or an improvement each time a
Fixes tag is added.

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

This is a fairly common misconception around what happens in the -rc
cycles.

The statistic is that about 70% of commits that have a stable tag but no
fixes tag actually fix something in the previous releases rather than
something that was introduced in the current merge window.

When you couple that with commits that are stable tagged, nearly 85% of
commits in each -rc release actually address something that happened
prior to the merge window.

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

These were the rules for a while, and the issue was that there were so
many commits without a stable tag that needed to be backported that the
model of "later discovered" simply overwhelmed the process.

We can't go back to that again.

-- 
Thanks,
Sasha