Re: Linking Patchwork with Sashiko?

[Jacopo Mondi <jacopo.mondi@ideasonboard.com>]

Hi Ted,

On Wed, Jul 15, 2026 at 01:31:00PM -0400, Theodore Tso wrote:
> On Wed, Jul 15, 2026 at 09:59:57AM -0500, Jacopo Mondi wrote:
> > Far-fetched review comments, very convincing word salads mixed with
> > valuable findings have often been escalated by authors to maintainers
> > to have them distil the good from the bad.
>
> That hasn't been my experience with ext4.  As far as signal to noise,
> the main issue is one where pre-existing issues are flagged in
> multiple patches in the patch series.  However, (a) Romain knows about
> this, and a fix is in the works, and (b) it's flagged as a
> pre-existing issue --- and we tell newcomers that they are free to
> disgard pre-existing issues, but if they do want to fix it, in most
> cases do it as a separate patch (or in a separate patch series) and to
> avoid folding it into the current patch --- especially if the fix is
> non-trivial.

This is exactly happened to me last week.

I got fooled by a Sashiko reported issue on patch for a driver I
maintain. I asked the developer to address it, he did so in a separate
patch, people got involved, lost quite some time on it, it ended up
being a false positive.

Now, one could blame me for being fooled by Sashiko. One could say
that the above described process is exactly what we do: discuss code
to make it better.

I can agree with both the above point.

Fact is, reviewers/maintainers are scarce, and I got my time sucked in
by an hallucination. It could happen with people too, but the rate at
which LLMs produce output is super-human.

This might sound just one anecdotal experience, but is not just one
off. That's what I ear from most people doing reviews and driver
maintainership, and that's the reason the linux-media summit decided
to keep Sashiko reviews in a separate mailing list as an opt-in for
interested reviewers: to avoid overloading the most scarce resource we
have: maintainers and reviewers.

>
> > All discussions around AI inevitably ends being about principles and
> > good vs bad. I'm surprised Linus and Ted had to weight in to re-state
> > the "we're not against AI!" principle while I would like to discuss
> > signal-to-noise metrics instead.
>
> If it makes sense for a subsystem to move reviews to a separate list,
> by all means, that should be up to the subsystem maintainers.  There

In a large subsystem, where multiple people does reviews and effective
maintainership of drivers and large parts of the subsystem, these
kind of decision have to be made by consensus among the ones investing
time and energy to maintain the subsystem.

That's what we did during the linux-media summit.

> has been quite a lot of discussion about how we should accomodate
> people who object to AI by dumping more work on maintainers, and
> that's the part that I object to.

Sorry for not being clear. My point is exactly this: so far, LLM
reviews have proven to be time and energy consuming for maintainers
and reviewers.

Will they get better ? Surely.

At this time it's imposing more work on the active member of the
community.

>
> One of the things that really excites me about Shashiko is that it
> reduces my workload.  Whereas the false positives from Syxbot and

I'm really surprised how your experience differ from the one of most
people I interact with.

Maybe it's a question of what your role in the development pyramid is?

Who effectively does the first reviews on the list and interfaces
directly with contributors might be more affected by slop compared to
top-end maintainers that receive the end product ?

> oss-fuzz have caused me more work, not less, and has had significantly
> more noise than Shahiko.  (I've started outright ignoring oss-fuzz
> reports as a result, and the "respond within NN days or we will make
> our report public" has caused me to respond, "and this will say more
> bad things about oss-fuzz than my software"....)

>
> Cheers,
>
> 							- Ted