Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

[Takashi Iwai <tiwai@suse.de>]

On Tue, 16 Jul 2024 08:28:53 +0200,
Greg KH wrote:
> 
> On Mon, Jul 15, 2024 at 01:47:14PM -0700, Dmitry Torokhov wrote:
> > On Mon, Jul 15, 2024 at 02:06:55PM -0500, Dan Carpenter wrote:
> > > On Mon, Jul 15, 2024 at 02:00:00PM -0400, Theodore Ts'o wrote:
> > > > On Sun, Jul 14, 2024 at 04:18:00PM -0400, Sasha Levin wrote:
> > > > > From my experience, most issues tracked by regzbot and fixed upstream
> > > > > don't actually have a stable tag. Here's one I just looked at a few days
> > > > > ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f451fd97dd2b78f286379203a47d9d295c467255
> > > > > 
> > > > > And I'm actually happy to point to that one as an example because the
> > > > > ext4 folks are usually great about stable tags.
> > > > >
> > > > > Should we have not taken that commit?
> > > > 
> > > > Yep, that's just a mistake on our (my) part; you should have taken
> > > > that commit, and my thanks for taking it without asking us.
> > > > 
> > > > That being said, maybe one path forward is that the stable team
> > > > *should* be asking the subsystem maintainers about.  "Hey, the
> > > > following commits appear to be backported, but you didn't add a cc:
> > > > stable.  We plan to backport them unless you complain."  This has the
> > > > benefit of giving feedback to the subsystem maintainers that they they
> > > > missed tagging some number of commits, which might remind them to do
> > > > better, or make them decide that they want to do something more
> > > > explicit, such as have their own stable backports initiative ala XFS.
> > > > 
> > > > More generally, it seems to me that we are conflating multiple issues
> > > > here in this discussion which may be making it harder for us make
> > > > progress on the question.
> > > > 
> > > > 1) There are some subsystems who don't care about tagging commits,
> > > >    either Fixes: or Cc: stable, or both;
> > > > 
> > > > 2) There are subsystems which are trying to appropriately tag commits, but:
> > > >    a) Sometimes they will make a mistake, and forget to cc: stable
> > > >    b) Sometimes it's too hard (tm) to figure out what is the commit which
> > > >       introduces the regression, so they either make up something (e.g.,
> > > >       hmm, it looks like commit XYZ changes one of the line that is touched
> > > >       by the patch, so <shrug emoji>), or they will add a Cc: stable but
> > > >       not supply a Fixes: tag
> > > 
> > > Too hard doesn't work as an excuse because someone has to figure it out,
> > > and it may as well be the subsystem expert.
> > > 
> > > I've already added a checkpatch warning when people CC stable but don't
> > > include a Fixes tag.  I also plan to start going back to maintainers
> > > and manually asking them for Fixes tags.  This will be attached to the
> > > patch.msgid.link URL so the stable tooling can pick up Fixes tags which
> > > are added later.
> > > 
> > > The one question I have is for patches which pre-date git.  I was told
> > > to leave the Fixes tag off in that case, but I think that's out of date.
> > > It's more useful to say "Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")".
> > 
> > If a thing was there since before git and only now is being discovered
> > it either needs to be explicitly marked for stable with cc: or we can
> > just keep the fix in newer kernels. IMO this particular "Fixes" tag does
> > not bring any value.
> 
> On the contrary, if I see just a "cc: stable" and no "Fixes:" tag, I do
> a "best effort" to backport to all current stable/lts trees.  If it
> fails on 5.15 and older, great, I don't warn anyone about that as there
> was no Fixes: tag for me to know how far back it should go.

That's what I expected for the cases I put only Cc-to-stable; they
have been mostly some trivial quirks only for new devices, and the
stuff that can be taken safely when applicable -- otherwise just
skip.


thanks,

Takashi