From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Theodore Tso <tytso@mit.edu>
Cc: 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 19:11:11 +0300 [thread overview]
Message-ID: <20260715161111.GC1778116@killaraus.ideasonboard.com> (raw)
In-Reply-To: <alcBvuIMEGSjAD1R@mit.edu>
Hi Ted,
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.
If you use generative AI to detect issues, find an actionable comment
after careful verification and tell me why you find it actionable, I
will treat it as a review from Ted Ts'o. I may think your moral compass
isn't tuned as mine, but I can still hold you in high regard despite
differences in opinions. I certainly wouldn't ignore a serious security
issue you would report in that way.
If you start letting obvious false positives through your filter, or
significantly more false positives, then my trust in your reviews and
skills as a maintainer will diminish over time. The same would apply if
you started rambling nonsensically on your own. Occasional mistakes will
likely have little impact as we all make mistakes, especially if you
acknowledged such mistakes.
What this does *not* mean to me is creating an environment where we
pretend those technologies don't exist. The "put your head in the sand"
comment from Linus elsewhere in this thread is a bit of a
mischaracterization. To his defence, discussions on this topic on kernel
mailing lists have been quite heated and prone to mischaracterization.
I have talked with multiple people across the whole spectrum from
neutral to very negative opinions about generative AI. One thing that
struck me is how a large number of those people feel they're not allowed
to express any opinion that is not strongly pro-AI. Maybe listening to
each other could be a good first step towards better understanding. I
hope we as a community share enough common values to consider important
for everybody to feel heard.
On a side note, I have submitted a BoF proposal on this topic for the
OSS Europe conference (quite ironically, in the AI track). The goal is
to give a place for the people who feel the community only listens to
the pro-AI voices and rejects all other opinions. I don't know if it
will be accepted.
> > 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.
> 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.
> How do we balance the needs and time of maintainers with patch
> authors? I don't think it's obvious that we *MUST* bend over
> backwards to oblige the needs of all patch authors.
Does the above bring some clarification to this question, or at least
useful examples to continue a constructive discussion ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2026-07-15 16:11 UTC|newest]
Thread overview: 54+ 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 16:43 ` Laurent Pinchart
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 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 [this message]
2026-07-15 17:00 ` Jan Kara
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 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 17:41 ` Jason Gunthorpe
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=20260715161111.GC1778116@killaraus.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=debarbos@redhat.com \
--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.