From: Roman Gushchin <roman.gushchin@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: debarbos@redhat.com, Joanne Koong <joannelkoong@gmail.com>,
sashiko@lists.linux.dev, Christoph Hellwig <hch@lst.de>,
"Darrick J. Wong" <djwong@kernel.org>,
clm@meta.com
Subject: Re: Full subsystem codebase scan for identifying pre-existing issues?
Date: Mon, 17 Aug 2026 20:12:29 +0000 [thread overview]
Message-ID: <7ia4a4qkfqvm.fsf@castle.c.googlers.com> (raw)
In-Reply-To: <20260729190158.fa32a6fd1f06d5103add0533@linux-foundation.org> (Andrew Morton's message of "Wed, 29 Jul 2026 19:01:58 -0700")
Andrew Morton <akpm@linux-foundation.org> writes:
> On Wed, 29 Jul 2026 21:43:26 -0400 Derek Barbosa <debarbos@redhat.com> wrote:
>
>> Hi,
>>
>> > Currently, they're flagged on patch reviews, which can be
>> > a bit frustrating for contributors who didn't introduce the problem,
>> > and adds a bit of noise for maintainers/reviewers looking at the
>> > Sashiko report.
>>
>> Unfortunately, you aren't the first to report a problem with these.
>>
>> Currently, in the 11th stage instruction in the code, pre-existing issues are
>> propagated in the report like so:
>>
>> <snip>
>>
>> CRITICAL RULE: If a finding is flagged as pre-existing (`\"preexisting\":
>> true`), you MUST explicitly state in your inline comment that this issue is
>> pre-existing and was not introduced by the patch under review. Use phrasing like
>> \"This isn't a bug introduced by this patch, but...\" or \"This is a
>> pre-existing issue, but...\" to start the comment.
>>
>> </snip>
>>
>> Instead of them replying inline with "This isn't a bug introduced by this patch,
>> but by..." or "This is a pre-existing issue, but does..." how would you like to
>> see this information presented/conveyed?
>>
>> I created an issue here [2]
>>
>> [2] https://github.com/sashiko-dev/sashiko/issues/381
>
> "To a separate section" is OK.
>
> I wouldn't want to lose the pre-existing issue reporting. I don't see
> that an author is obligated to address these things (although they
> often do). But I like to see that the pre-existing things are brought
> to the official maintainer's attention.
>
>
> And yes, it's all very disorganized and error-prone. How nice would it
> be for Maintainer to think "hm, I have a few hours to spare - what bug
> reports are there against my stuff". Then click on a link.
As Chris mentioned in the thread, we're working on it: a dashboard
of corresponding issues available to all maintainers.
Thanks
next prev parent reply other threads:[~2026-08-17 20:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 20:34 Full subsystem codebase scan for identifying pre-existing issues? Joanne Koong
2026-07-30 1:43 ` Derek Barbosa
2026-07-30 2:01 ` Andrew Morton
2026-08-17 20:12 ` Roman Gushchin [this message]
2026-07-30 11:20 ` Chris Mason
2026-07-31 0:34 ` Joanne Koong
2026-07-31 12:29 ` Derek Barbosa
2026-08-17 20:18 ` Roman Gushchin
2026-08-17 20:15 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ia4a4qkfqvm.fsf@castle.c.googlers.com \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=clm@meta.com \
--cc=debarbos@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=joannelkoong@gmail.com \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.