Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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.

Thanks.

-- 
Dmitry