Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

[Greg KH <gregkh@linuxfoundation.org>]

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.

But if there is the "Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")" line, I
_know_ it should also go to older kernels, and so I send the "FAILED"
email letting everyone know something went wrong and that allows those
developers who watch for them, to pick them up and potentially provide a
working fix.

So yes, it does bring a load of value to do this, please do it if you
know it.

thanks,

greg k-h