Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

["NeilBrown" <neilb@suse.de>]

On Mon, 15 Jul 2024, James Bottomley wrote:
> On Sun, 2024-07-14 at 16:27 -0400, Sasha Levin wrote:
> > On Sun, Jul 14, 2024 at 12:27:55PM -0700, Linus Torvalds wrote:
> [...]
> > > I would hope that *all* commits improve on something. And if it's
> > > an actual fix to a previous commit, it should say so.
> > > 
> > > If it's just a random improvement, it shouldn't refer to a previous
> > > commit at all.
> > 
> > This is *one* view. I've observed that both individuals and companies
> > started requiring a fixes tag unless they're writing a new feature.
> > 
> > Heck, back in Google you couldn't commit anything that is not a new
> > feature unless the commit message had a "Fixes:" tag to make the bot
> > happy.
> 
> But we know how to enforce a unified view of process: we document it in
> Documentaion/process ... and indeed we already have a handling-
> regressions.rst which says:
> 
>     * Add a "Fixes:" tag to specify the commit causing the regression.

Interesting.  I don't think Fixes means that the target introduced a
regression, though that is one possibility.
Fixes could also mean that the target introduced a feature that didn't
quite work as intended.
Sometimes Fixes means that the target introduced a typo in a comment - I
wouldn't use it that way, but some people do and I find it hard to
disagree.
(and maybe all these targets do regress the "total perfection" score for
 Linux.....)

I'd generally be happy with any commit marked "Fixes" getting into a kernel that
contains the target.  In my mind the issues are more about:
 - how quickly should the fix land.  There is no easy answer.
 - Are Fixes focused on a backportable fix, or do they combine a fix with
   new functionality?  I think they are often quite focused, but it
   wouldn't hurt to often remind each other of the importance of focused
   fixes.

NeilBrown