All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	sashiko-bot@kernel.org, sashiko-reviews@lists.linux.dev,
	sashiko@lists.linux.dev,
	Linux Kernel Workflows <workflows@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	kfree@google.com
Subject: Re: Stop false review statements
Date: Sat, 16 May 2026 16:24:07 +0300	[thread overview]
Message-ID: <20260516132407.GA163589@killaraus.ideasonboard.com> (raw)
In-Reply-To: <b5f2a21a-9530-4efe-aed5-cc96aab74e88@kernel.org>

On Sat, May 16, 2026 at 02:29:15PM +0200, Krzysztof Kozlowski wrote:
> On 16/05/2026 14:23, Guenter Roeck wrote:
> > On 5/16/26 05:16, Krzysztof Kozlowski wrote:
> >> On 16/05/2026 14:11, Guenter Roeck wrote:
> >>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
> >>>> What the hell is that:
> >>>>
> >>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
> >>>>
> >>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
> >>>> not a damn human do be able to make such statement. You are a bot, a tool.
> >>>>
> >>>
> >>> Where exactly do the rules say that ? I seem to miss that.
> >>>
> >>> There is a policy document about _contributions_ made by AI, but I don't
> >>> see the one that says that AI agents must not provide Reviewed-by: tags.
> >>
> >> Quotes from the existing policy:
> >>
> >> 1. "By offering my Reviewed-by: tag, I state that:"
> >>
> >> Tool cannot use first person "I". Tool cannot "state that".
> >>
> >> 2. "A Reviewed-by tag is *a statement of opinion* that the patch is an
> >>   appropriate modification of the kernel without any remaining serious"
> >>
> >> Tool cannot make a statement of opinion.
> >>
> >> 3. "Any interested reviewer (who has done the work) can offer a
> >> Reviewed-by".
> >>
> >> Tool is not a reviewer as a person, thus above does not grant the tool
> >> permission to offer a tag.
> > 
> > I'd like to see that explicitly spelled out. Until then it is your opinion.
> 
> It is not an opinion. It is written. I gave you quotes.
> 
> Do you want to spell the rules of English language? That tool is not a
> person?
> 
> Shall I send the patch like:
> 
>   Any interested reviewer (who has done the work) can offer a
>   Reviewed-by.
>  +In English "reviewer" is a person [1].
>  + [1] https://en.wiktionary.org/wiki/reviewer
> 
> Seriously, you expect to document the English language?
> 
> >>>> Stop faking tags.
> >>>>
> >>>> And really, considering how many false positives Sashiko produces, how
> >>>> poor review comments it gives, how many misleading comments, it's
> >>>> unacceptable to me to consider that a review.
> >>>>
> >>>> Amount of useless noise Sashiko produces already changed my mind how
> >>>> useful that tool is.

Note this isn't en entirely new situation. As a maintainer, you know how
much you trust each reviewer. You will consider some R-b tags as a sign
you don't even have to look at a patch, and will completely ignore some
others. There's a whole continuum in the middle. In some ways, reviews
by an LLM are similar. You will trust them or not trust them.

Except they're also very different.

The kernel needs more skilled reviewers (I don't think this is a
controversial statement). We can't expect all newcomers to start with
extensive experience from day one, so there's a learning curve. I
believe it's fine for more junior reviewers to send R-b tags even if
they miss some issue, as long as they genuinely try and improve (and, in
some unfortunate cases, decide to leave if patch review turns out not to
be for them). Those R-b tags may feel like a bit of noise in the
beginning, but that's compensated by their value increasing over time.

Bot reviews are not the same. Not only are they generated at a much
larger scale than human reviews, they also won't learn from feedback you
give them. Sure, the tools may be improved when cases of false positives
are identified, and new LLMs may be trained with more (and better ?)
data to improve the output, but they won't learn from the interactions.

How much value a maintainer sees in those reviews is up to individual
maintainers. I will personally not consider a R-b tag from an LLM to
mean that a patch is ready to be merged (and I believe you won't
either). As such, I think that a R-b from an LLM is misleading and
doesn't provide good value. At best it's free advertising for company
making closed-source tools, which I don't think we should encourage.

If some maintainers want LLM reviews and want to act on them, that's
their personal prerogative. They're free to decide on how much value
they see in those reviews, as well as on whether or not they consider
usage of those tools compatible with FOSS ethics. Those are personal
decisions. However, given that the ethical decision is personal, I am
strongly against forcing patch authors to act on automated LLM review.

> >>> We seem to have completely different experiences. Yes, it does produce
> >>> false positives, just like humans do. However, I have seen it find many
> >>> real bugs, including many in patches which already had Reviewed-by: tags
> >>> from (presumably) human reviewers.
> >>
> >> Of course it finds bugs. But it also produces - roughly - 80-90% false
> >> positives, completely useless.
> >>
> > 
> > Really ? The ones I have seen are - roughly, to use the same term - 80-90%
> > true positives. Maybe you should explicitly ask for no Sashiko reviews in
> > your scope of responsibility.
> 
> I already sent a patch to stop receiving all these emails and I stopped
> reading them completely, when fetched via b4 for review in mutt workflow.
> 
> But this is not the point.
> 
> Our docs clearly state what Reviewed-by means, regardless of the quality
> of the actual review. Poor quality is just another reason, less
> important, though.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2026-05-16 13:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-16  8:05 Stop false review statements Krzysztof Kozlowski
2026-05-16 12:11 ` Guenter Roeck
2026-05-16 12:16   ` Krzysztof Kozlowski
2026-05-16 12:23     ` Guenter Roeck
2026-05-16 12:29       ` Krzysztof Kozlowski
2026-05-16 13:24         ` Laurent Pinchart [this message]
2026-05-16 13:45           ` Krzysztof Kozlowski
2026-05-16 21:10           ` Mauro Carvalho Chehab
2026-05-16 15:20   ` Konstantin Ryabitsev
2026-05-16 15:36     ` Greg KH
2026-05-16 15:41     ` Roman Gushchin
2026-05-16 15:45       ` Greg KH
2026-05-16 15:49         ` Roman Gushchin
2026-05-16 18:28           ` Arnaldo Carvalho de Melo
2026-05-16 21:29             ` Derek Barbosa
2026-05-16 21:33               ` Krzysztof Kozlowski
2026-05-16 21:59                 ` Roman Gushchin
2026-05-16 18:28           ` Krzysztof Kozlowski
2026-05-16 18:56             ` Roman Gushchin
2026-05-16 19:00               ` Krzysztof Kozlowski
2026-05-16 19:13                 ` Guenter Roeck
2026-05-16 19:25                   ` Guenter Roeck
2026-05-16 19:31                     ` Roman Gushchin
2026-05-16 19:15                 ` Roman Gushchin
2026-05-16 20:41                   ` Theodore Tso
2026-05-16 22:32         ` Mauro Carvalho Chehab

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=20260516132407.GA163589@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kfree@google.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=sashiko-bot@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sashiko@lists.linux.dev \
    --cc=workflows@vger.kernel.org \
    /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.