* Re: [PATCH 2/2] agents: add a skill to determine Fixes tags [not found] ` <7fa126fd22b4449cf63a7045f7cd959e106fac87.1791499378.git.sashal@kernel.org> @ 2026-10-10 9:40 ` Thorsten Leemhuis 2026-10-10 10:33 ` Michael S. Tsirkin 0 siblings, 1 reply; 3+ messages in thread From: Thorsten Leemhuis @ 2026-10-10 9:40 UTC (permalink / raw) To: Sasha Levin, workflows, ksummit Cc: linux-doc, linux-kernel, corbet, skhan, rdunlap, broonie, tytso, Linux kernel regressions list On 10/9/26 00:54, Sasha Levin wrote: > > +A ``Fixes:`` tag identifies the commit that introduced the bug being fixed. [...] Sorry for partly hijacking this, but it seems appropriate while we are at it: What exactly is the right commit to specify when it comes to a regression caused by a change that exposed a way older bug? The change that exposed it? The change that introduced it in the first place? Both? I'd tend to "both", but I guess some people might consider this as too noisy. I've seen occasional discussions about this and our docs for humans are a bit vague here: Documentation/process/submitting-patches.rst says: ""If your patch fixes a bug in a specific commit, e.g. you found an issue using git bisect, please use the ‘Fixes:’ tag with at least the first 12 characters of the SHA-1 ID, and the one line summary. [...] 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"" And Documentation/process/5.Posting.rst says: ""One tag is used to refer to earlier commits which introduced problems fixed by the patch:"" Ciao, Thorsten ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 2/2] agents: add a skill to determine Fixes tags 2026-10-10 9:40 ` [PATCH 2/2] agents: add a skill to determine Fixes tags Thorsten Leemhuis @ 2026-10-10 10:33 ` Michael S. Tsirkin 2026-10-10 13:45 ` Sasha Levin 0 siblings, 1 reply; 3+ messages in thread From: Michael S. Tsirkin @ 2026-10-10 10:33 UTC (permalink / raw) To: Thorsten Leemhuis Cc: Sasha Levin, workflows, ksummit, linux-doc, linux-kernel, corbet, skhan, rdunlap, broonie, tytso, Linux kernel regressions list On Sat, Oct 10, 2026 at 11:40:56AM +0200, Thorsten Leemhuis wrote: > On 10/9/26 00:54, Sasha Levin wrote: > > > > +A ``Fixes:`` tag identifies the commit that introduced the bug being fixed. [...] > > Sorry for partly hijacking this, but it seems appropriate while we are > at it: > > What exactly is the right commit to specify when it comes to a > regression caused by a change that exposed a way older bug? The change > that exposed it? The change that introduced it in the first place? Both? > I'd tend to "both", but I guess some people might consider this as too > noisy. > > I've seen occasional discussions about this and our docs for humans are > a bit vague here: > > Documentation/process/submitting-patches.rst says: > ""If your patch fixes a bug in a specific commit, e.g. you found an > issue using git bisect, please use the ‘Fixes:’ tag with at least the > first 12 characters of the SHA-1 ID, and the one line summary. > [...] > 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"" > > And Documentation/process/5.Posting.rst says: > ""One tag is used to refer to earlier commits which introduced problems > fixed by the patch:"" > > Ciao, Thorsten I'd say the one exposed it. this way it is useful to answer the question "do i need this fix". ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 2/2] agents: add a skill to determine Fixes tags 2026-10-10 10:33 ` Michael S. Tsirkin @ 2026-10-10 13:45 ` Sasha Levin 0 siblings, 0 replies; 3+ messages in thread From: Sasha Levin @ 2026-10-10 13:45 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Thorsten Leemhuis, workflows, ksummit, linux-doc, linux-kernel, corbet, skhan, rdunlap, broonie, tytso, Linux kernel regressions list On Sat, Oct 10, 2026 at 06:33:05AM -0400, Michael S. Tsirkin wrote: >On Sat, Oct 10, 2026 at 11:40:56AM +0200, Thorsten Leemhuis wrote: >> On 10/9/26 00:54, Sasha Levin wrote: >> > >> > +A ``Fixes:`` tag identifies the commit that introduced the bug being fixed. [...] >> >> Sorry for partly hijacking this, but it seems appropriate while we are >> at it: >> >> What exactly is the right commit to specify when it comes to a >> regression caused by a change that exposed a way older bug? The change >> that exposed it? The change that introduced it in the first place? Both? >> I'd tend to "both", but I guess some people might consider this as too >> noisy. >> >> I've seen occasional discussions about this and our docs for humans are >> a bit vague here: >> >> Documentation/process/submitting-patches.rst says: >> ""If your patch fixes a bug in a specific commit, e.g. you found an >> issue using git bisect, please use the ‘Fixes:’ tag with at least the >> first 12 characters of the SHA-1 ID, and the one line summary. >> [...] >> 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"" >> >> And Documentation/process/5.Posting.rst says: >> ""One tag is used to refer to earlier commits which introduced problems >> fixed by the patch:"" >> >> Ciao, Thorsten > >I'd say the one exposed it. this way it is useful to answer >the question "do i need this fix". I'd suggest the original commit that introduced the issue, or if you really want to - add two Fixes: tags. My reasoning is that if there were holes around the reachability of the issue in the past, we want to land the fix on all relevant trees, rather than just the ones affected by the most recent case that enabled it to happen. For example, let's say an issue was introduced in v6.5 and was reachable by one codepath. Later, in v6.7, we refactored some code and made is issue benign by removing the only codepath that could reach it. Even later, a new commit in v7.0 made the issue reachable again. If our Fixes: tag points to the v7.0 re-introduction, then we will miss the backport to the v6.6 tree. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-10 13:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <cover.1791499378.git.sashal@kernel.org>
[not found] ` <7fa126fd22b4449cf63a7045f7cd959e106fac87.1791499378.git.sashal@kernel.org>
2026-10-10 9:40 ` [PATCH 2/2] agents: add a skill to determine Fixes tags Thorsten Leemhuis
2026-10-10 10:33 ` Michael S. Tsirkin
2026-10-10 13:45 ` Sasha Levin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox