Re: Proposal: Enhancing Commit Tagging for Stable Kernel Branches

[Dan Carpenter <dan.carpenter@linaro.org>]

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

regards,
dan carpenter