From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jan Kara <jack@suse.cz>
Cc: Theodore Tso <tytso@mit.edu>,
Roman Gushchin <roman.gushchin@linux.dev>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Derek Barbosa <debarbos@redhat.com>,
Matthieu Baerts <matttbe@kernel.org>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Steven Rostedt <rostedt@goodmis.org>,
users@kernel.org,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Stephen Finucane <stephenfin@redhat.com>
Subject: Re: Linking Patchwork with Sashiko?
Date: Wed, 15 Jul 2026 23:28:08 +0300 [thread overview]
Message-ID: <20260715202808.GN1778116@killaraus.ideasonboard.com> (raw)
In-Reply-To: <j4jhhj6rw6kgem73slctakegtoirqmngbejbabfnfwtyshdlgp@itpaup6ghuod>
On Wed, Jul 15, 2026 at 07:00:39PM +0200, Jan Kara wrote:
> Hi Laurent!
Hi Jan :-)
> On Wed 15-07-26 19:11:11, Laurent Pinchart wrote:
> > On Tue, Jul 14, 2026 at 11:54:43PM -0400, Theodore Tso wrote:
> > > On Wed, Jul 15, 2026 at 03:59:09AM -0500, Laurent Pinchart wrote:
> > > > I believe we should
> > > > follow the first two recommendations of the Software Freedom Conservancy
> > > > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> > > >
> > > > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> > >
> > > It's not clear to me that the SFC document is particularly applicable
> > > for the use of LLM's beyond the use case of generating code which is
> > > contributed to FOSS projects.
> > >
> > > Things get a lot more complicated when we're considering the use of
> > > LLM's to (a) review code, (b) automate the analysis of a bug report or
> > > stack trace, or (c) automate backporting a patch to LTS kernel.
> > >
> > > Consider the first recommendation, "The FOSS community should support,
> > > not just tolerate, those who outright reject LLM-gen-AI systems." If
> > > someone rejects LLM-gen-AI systems, and the LTS kernel contains
> > > patches which are automated backported, and they object, are we bound
> > > to forswear the use of automated backport technologies?
> >
> > I think this is a bit of an extreme example that does not reflect the
> > rationale for the SFC recommandations. Note recommendation 3, which
> > states
> >
> > "FOSS projects should not shun contributors who choose to use LLM-gen-AI
> > systems"
> >
> > I hold personal opinions on what I consider is or isn't ethical in this
> > context, and I also understand that ethical principles have a personal
> > dimension. Within the boundaries of the rules of our community, people
> > should be entitled to have different opinions. I don't think anyone is
> > seriously trying to *force* the whole kernel community to ban usage of
> > generative AI (believing in chances of complete success would be a bit
> > foolish at this time), not even the people having the most extreme moral
> > compasses pointing towards that direction.
> >
> > > What if someone reports a bug with a kernel stack trace, and someone
> > > uses an LLM agent to analyze their bug report and find a fix. What
> > > does it mean to "support somone who outright rejects the use of
> > > LLM-gen-AI systems" in that case?
> >
> > My interpretation (which conveniently matches my opinion) is that
> > developers should not be forced to directly *use* generative AI tools,
> > and should not be forced to *process* unfiltered output of those tools.
> >
> > What does this translate to in practice ? I will need to sleep over it
> > for at least a few nights to formulate it clearly. I know that I (along
> > numerous other people) have strong negative feelings if forced to
> > justify myself against unchecked output of an LLM-based review bot, or
> > to review patches where the submitter has clearly not invested
> > substantial time in making the contributions as good as they can. When
> > this happens with human reviewers or developers, they lose trust points
> > and end up being ignored. I don't want to be forced to hold LLMs in
> > higher regards than that.
>
> I'm not sure I understand here. Do you say you have moral issues if you
> should read unchecked LLM output? Or is it just that you find noise /
> signal ratio too bad with LLM output so you find it a waste of your time
> (and thus feel badly if you were forced to waste this time)? Or something
> else?
I feel that justifying myself against generative AI hallucinations that
are blindly trusted by maintainers makes me feel diminished as a human.
No later than yesterday a friend of mine pointed me to a mail thread
where sashiko referenced code that has never existed in the kernel, and
the maintainer blindly trusted the comment and asked the patch author to
fix that issue, seemingly doubling down when told the code didn't exist.
Depending on one's beliefs, this can be easy to brush off, but such
incidents can easily make you question your value in a community where
maintainers would by default trust sashiko over an experienced
developer.
> > > > I expect maintainers who want to act on sashiko reviews to triage and
> > > > verify them first before bothering authors
> > >
> > > As a maintainer, I don't believe I should be forced to rephrase a
> > > Sashiko report just because a patch author "outright rejects" LLM's.
> >
> > I don't think I have called for that. What I believe is that triaging
> > LLM reviews should not be forced onto contributors.
>
> Frankly, so far I see the issue with LLM review similarly as a dillema we
> used to have with checkpatch. It was finding some sensible issues but often
> the suggestions were also misleading. So some people just found it a waste
> of time and ignored it, other people didn't accept patches if it didn't
> pass checkpatch.
>
> I guess nobody can really force contributors to read LLM reviews but OTOH
> if you see LLM review keeps finding real issues in the work of some
> contributor and you as a maintainer have to go and filter them for the
> contributor (instead of contributor doing this work on their own), then you
> naturally reduce priority of such contributions because it is more work for
> you as a maintainer to deal with them...
I understand the problem. That leads to the next question though: what
will happen when developers will have to pay for those tools ? Will
people who don't want to pay OpenAI, Anthropic or any of the similar
companies with dubious ethics be treated as second-class kernel
contributors and be deprioritized ?
> > > For that matter, I don't believe I'm obliged to accept patches from
> > > someone who forces me to do extra work because they refuse to look at
> > > Sashiko reviews....
> >
> > Flipping the argument, should contributors be obliged to do extra work
> > that make them feel diminished as a human ? I'm talking here about
> > justifying themselves against LLM arguments that have not been analyzed
> > by a maintainer first.
>
> You write here about "feeling diminished" or "justifying themselves" and
> I'm not sure I get it. If you get a complaint from some CI running
> checkpatch or say coverity which is bogus (or perhaps correct?), do you
> also feel diminished or needing to justify? I just don't see how LLMs are
> different here...
No, I don't get the same feeling. This is due to multiple factors. One
of them is due to the more deterministic nature of those tools. I know a
build failure from the 0day bot is a build failure. I know what warnings
from checkpatch can be ignored in a given subsystem. I know that I can
reply to some reported issues saying they're false positives and won't
be asked for a full justification. I know that the tool will not deploy
language aimed at convincing me to accept bogus findings. I know what
patterns of false positives to expect. More importantly, I know
maintainers will not blindly side with the tool against me by default.
Another factor that of course plays here is not having the same kind of
ethical concerns regarding static analyzers or build bots.
> And just to be sure: I'm genuinely trying to understand
> your position because so far I don't understand it.
That shows through the way you're asking questions, I really appreciate
it.
> For example when I get Sashiko feedback for my patches, I just ignore the
> comments I find bogus and address those that I find to the point in the
> next revision. If I see Sashiko found something fundamental, I'll also
> reply to the thread to notify human reviewers that I'll have to do a larger
> rewrite so they don't have to waste human time with reviewing this version
> of the patches.
Some maintainers have said they expect authors to justify themselves for
all the false positives.
To be honest, I expect that some authors are already gaming all this by
using generative AI to write convincing explanations to dismiss comments
as false positives, even when they're not, and I don't expect most
maintainers would notice.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2026-07-15 20:28 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260528144627.1ae09ff2@foz.lan>
[not found] ` <1372F826-5513-4EB2-AE27-1DC0D2DE0AEB@linux.dev>
[not found] ` <20260529083100.6710b6cd@foz.lan>
[not found] ` <20260529083801.2c7e8990@foz.lan>
[not found] ` <ahmwUk0uXTkdwohf@debarbos-thinkpadt14gen5.rmtusma.csb>
2026-05-30 8:30 ` Linking Patchwork with Sashiko? Mauro Carvalho Chehab
2026-05-30 15:57 ` Roman Gushchin
2026-05-30 18:00 ` Mauro Carvalho Chehab
2026-05-30 18:49 ` Mauro Carvalho Chehab
2026-05-30 18:53 ` Mauro Carvalho Chehab
2026-06-02 15:51 ` Derek Barbosa
2026-06-02 16:51 ` Mauro Carvalho Chehab
2026-06-02 18:39 ` Jason Gunthorpe
2026-06-02 20:29 ` Mauro Carvalho Chehab
2026-06-02 20:13 ` Roman Gushchin
2026-06-02 20:39 ` Mauro Carvalho Chehab
2026-06-02 20:44 ` Roman Gushchin
2026-06-02 23:50 ` Matthieu Baerts
2026-06-03 3:35 ` Mauro Carvalho Chehab
2026-06-03 3:49 ` Roman Gushchin
2026-06-04 6:52 ` Mauro Carvalho Chehab
2026-06-07 17:56 ` Mauro Carvalho Chehab
2026-06-30 20:32 ` Derek Barbosa
2026-07-10 5:45 ` Mauro Carvalho Chehab
2026-07-10 6:39 ` Mauro Carvalho Chehab
2026-07-11 1:01 ` Roman Gushchin
2026-07-13 7:55 ` Mauro Carvalho Chehab
2026-07-13 9:41 ` Laurent Pinchart
2026-07-13 20:04 ` Mauro Carvalho Chehab
2026-07-14 22:55 ` Roman Gushchin
2026-07-15 0:59 ` Laurent Pinchart
2026-07-15 2:00 ` Roman Gushchin
2026-07-15 3:06 ` Linus Torvalds
2026-07-15 12:21 ` Jori Koolstra
2026-07-15 16:50 ` Steven Rostedt
2026-07-15 18:13 ` Nicolas Dufresne
2026-07-15 19:12 ` Laurent Pinchart
2026-07-15 19:27 ` Nicolas Dufresne
2026-07-15 20:03 ` Laurent Pinchart
2026-07-15 16:43 ` Laurent Pinchart
2026-07-15 23:28 ` lyude
2026-07-15 7:59 ` Jacopo Mondi
2026-07-15 8:40 ` Mauro Carvalho Chehab
2026-07-15 17:31 ` Theodore Tso
2026-07-15 12:38 ` Mark Brown
2026-07-15 16:28 ` Laurent Pinchart
2026-07-15 21:08 ` Roman Gushchin
2026-07-15 23:20 ` Steven Rostedt
2026-07-16 0:09 ` Roman Gushchin
2026-07-15 3:54 ` Theodore Tso
2026-07-15 7:13 ` Mauro Carvalho Chehab
2026-07-15 12:42 ` James Bottomley
2026-07-15 16:18 ` Laurent Pinchart
2026-07-15 16:53 ` James Bottomley
2026-07-15 17:09 ` Laurent Pinchart
2026-07-15 16:11 ` Laurent Pinchart
2026-07-15 17:00 ` Jan Kara
2026-07-15 20:28 ` Laurent Pinchart [this message]
2026-07-15 20:36 ` James Bottomley
2026-07-15 20:42 ` Laurent Pinchart
2026-07-16 0:14 ` Roman Gushchin
2026-07-15 23:32 ` Steven Rostedt
2026-07-16 0:03 ` Roman Gushchin
2026-07-15 17:14 ` Theodore Tso
2026-07-15 17:35 ` Miguel Ojeda
2026-07-15 17:41 ` Laurent Pinchart
2026-07-15 18:18 ` Linus Torvalds
2026-07-15 18:51 ` Laurent Pinchart
2026-07-15 19:14 ` Linus Torvalds
2026-07-15 20:13 ` Laurent Pinchart
2026-07-15 16:28 ` Ihor Solodrai
2026-07-15 16:39 ` Laurent Pinchart
2026-07-15 17:12 ` Ihor Solodrai
2026-07-15 17:35 ` Mark Brown
2026-07-15 18:39 ` Ihor Solodrai
2026-07-15 20:32 ` Mark Brown
2026-07-15 19:06 ` Laurent Pinchart
2026-07-15 21:13 ` Theodore Tso
2026-07-15 17:41 ` Jason Gunthorpe
2026-07-15 19:10 ` Laurent Pinchart
2026-07-15 19:55 ` Mark Brown
2026-07-15 19:38 ` Dmitry Torokhov
2026-07-15 21:27 voste62ocr
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=20260715202808.GN1778116@killaraus.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=debarbos@redhat.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=konstantin@linuxfoundation.org \
--cc=linux-media@vger.kernel.org \
--cc=matttbe@kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=stephenfin@redhat.com \
--cc=tytso@mit.edu \
--cc=users@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.