Re: [PATCH v4 3/5] agents: add a skill to determine stable tags
From: Thorsten Leemhuis
Date: Wed Oct 21 2026 - 02:56:58 EST
On 10/20/26 18:16, Sasha Levin wrote:
> Whether a fix needs a stable tag, and which releases it should reach, is
> decided by hand and is often missed or left too broad. Add a skill that
> [...]
Thx for this!
> +
> +Judge a change by what it does, not by how its description labels it: a
> +"cleanup" that releases a resource on an error path fixes a leak. In practice,
> +the stable trees take:
> +
Shouldn't something like "It fixes a user-reported regression" be in
here -- maybe even at the top of the list given that "no regressions" is
our #1 rule?
One problem with that is that LLMs from what I see in sashiko's output
might interpret "regression" as "something that changed to the worse"
while we usually mean "something which used to work for somebody broke".
Side note: Ideally LLMs would have a way to clearly identify such
regression fixes. Sadly that idea didn't get traction when I suggested
it two years ago at the maintainers summit. Maybe it's time to revisit
it, as that would allow reviewers and maintainers to differentiate (and
thus prioritize if they want) regression fixes in the days of LLM patch
influx.
> +- Fixes for crashes, oopses, BUG and WARN splats, hangs, lockups, RCU stalls,
> + deadlocks, data corruption and security issues.
> +- Fixes for use-after-free, double free, NULL pointer dereferences,
> + out-of-bounds accesses, integer overflows, uninitialized data, reference
> + counting errors, and memory or resource leaks.
> +- Fixes for races, including data races.
> +- Fixes for incorrect behavior, such as wrong results, wrong hardware
> + programming, or endianness and type errors.
> +- Fixes for problems reported by syzbot, other fuzzers, or the KASAN, KMSAN,
> + KCSAN and UBSAN sanitizers.
> +- New device IDs and quirks for drivers that exist in the stable trees, device
> + tree fixes, and device tree additions for hardware that existing drivers
> + support.
> +- Corrections to documentation that is wrong.
> +- Performance fixes that prevent lockups, stalls or hangs.
> +- Reverts of commits that are in a released kernel.
> +- Fixes for bugs introduced by commits that were backported to stable.
Regarding the "backported" in the last point and related to my earlier
comment:
What about fixes for bugs or regressions that made it to stable series
via a mainline release? Say some change merged in the 7.3 cycles caused
a bug that is reported only now that 7.3 is out -- that should get a
stable-tag to end up in 7.3.y, even if the change was never backported
to earlier stable series. Not sure how to phrase that without making the
LLM put a stable tag on everything with a Fixes: tag. :-/
Ciao, Thorsten