On Tue, Oct 13, 2026 at 12:42:19AM -0400, Michael S. Tsirkin wrote: > On Mon, Oct 12, 2026 at 05:34:49PM -0400, Sasha Levin wrote: > > Blame and existing Fixes tags can point to code movement instead of the > > change that introduced a bug. Add a read-only investigation procedure > > that traces historical behavior and checks candidate commits against > > their parents before returning a tag with supporting evidence. > > > > Keep the skill entry point and procedure together under > > agents/skills/find-fixes/. Connect the procedure to the coding-assistant > > guidance so bug fixes get verified attribution before finalization. > > > > If the origin cannot be established, return no trailer and keep the fix > > as a draft. Applying the tag and writing the commit message remain outside > > the skill. > > > > Validated with controlled histories covering moved code, changed > > preconditions, incorrect tags, shallow history, and reintroduction after > > a revert, as well as a real kernel fix. > > > > Assisted-by: LLM > > Signed-off-by: Sasha Levin <[email protected]> > > Current documentation states: > > A Fixes: tag indicates that the patch fixes a bug in a previous commit. > It > is used to make it easy to determine where an issue originated, which > can help > review a bug fix. This tag also assists the stable kernel team in > determining > which stable kernel versions should receive your fix. This is the > preferred > method for indicating a bug fixed by the patch. See > :ref:`describe_changes` > for more details. > > > the second part is easy to miss, so "what about an old bug in commit A > commit B exposes"
This is pretty common for Makefile cleanups which enable COMPILE_TEST etc. The Fixes tag should point to the commit which introduces the bug and not the one that exposes it. Someone could backport the original patch or expose the bug a different way. > and "what if the bug both in commit A and commit B" > are pretty common questions. > This sentence is missing a verb. I don't understand the question. > > > > Worth answering, maybe, and maybe here: the implication of the "stable > kernel team" rule is that the meaning of the tag is actually: "if you > have commit A then you need this commit". > The Fixes tag is useful for stable, but that's not the only point. It also means that if you don't have the commit, then you don't need the fix. It's also useful for training AI for example. Someone told me that the netdev team was leaving Fixes tags off patches that they didn't want to be backported to stable. But when I looked at it, it was documentation stuff that is really debatable if it deserves a Fixes tag or not. There are some gray areas. regards, dan carpenter
