The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: Lorenzo Stoakes <ljs@kernel.org>
Cc: SJ Park <sj@kernel.org>, Jeff Layton <jlayton@kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Justin Stitt <justinstitt@google.com>,
	Carlos Maiolino <cem@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Jori Koolstra <jkoolstra@xs4all.nl>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Brian Foster <bfoster@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	David Disseldorp <ddiss@suse.de>, Mark Brown <broonie@kernel.org>,
	Jani Nikula <jani.nikula@intel.com>, Jens Axboe <axboe@kernel.dk>,
	David Hildenbrand <david@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	"Christian Brauner (Amutable)" <brauner@kernel.org>,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Documentation: remove the requirement for LLM attribution
Date: Thu,  2 Jul 2026 16:05:40 -0700	[thread overview]
Message-ID: <20260702230540.98160-1-sj@kernel.org> (raw)
In-Reply-To: <akaWnQ5Pkg_676B-@lucifer>

On Thu, 2 Jul 2026 17:50:15 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:

> On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
> > On Thu, 2026-07-02 at 18:19 +0200, Greg KH wrote:
> > > On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > > > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > > > We've had this requirement in place in the Documentation for several
> > > > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > > > is quite low.
> > > > > > >
> > > > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > > > the LLMs in good faith, not everyone does for various reasons.
> > > > > >
> > > > > > Then let's move to get people to follow it.
> > > > > >
> > > > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > > > >
> > > > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > > > using a LLM so that I can review it as-such.  And if I think someone is
> > > > > > not reporting that, I can ask for them to properly attribute it and if
> > > > > > they lie, well, that's on them.
> > > > > >
> > > > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > > > >
> > > > > > We want to know if a LLM is being used.
> > > > >
> > > > > But why? What do you intend to do with this information?
> > > > >
> > > > > Do you mean to use it as an indicator that the patch should receive
> > > > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > > > it to generate some sort of statistics at a later time?
> > > >
> > > > I use the information to decide how to review the patch, and what level
> > > > of priority to give it. For that usage I don't need a tag, but I need
> > > > the information in some human-readable form at patch submission time.
> > >
> > > Same here.  I don't care about stats, I care about "how do I review this
> > > patch" and this gives me that signal that I need if faced with a
> > > llm-helped patch.
> > >
> > >
> >
> > Do we need a tag for this though?
> >
> > This seems like the kind of information that we would always require in
> > the cover letter of a series (or the little place in an individual
> > patch for comments that don't get merged). That would also allow you to
> > convey a lot more nuance about how it was used.
> >
> > ISTM asking people to disclose LLM usage in a cover letter would give
> > everyone what they want: Information about whether and possibly how an
> > LLM was used, and it also wouldn't clutter up the changelogs with these
> > tags.

I understand the concern is having the information in the git log.  I agree in
a level.  I wish cloning linux takes not too long time and huge traffic.  I
wish each commit message be lengthy only as much as needed.

> 
> It's much much clearer and easier to just have a standardised tag for that.
> 
> You can see that (and grep for that) immediately, vague paragraphs not so much.

I also agree having a formal tag can be convenient.  LWN's Assisted-by: tag
statistic was interesting enough to make me supporting this idea.

What about keep requesting this formal signature to the submitters, but also
formally allow (or, encourage) subsystem maintainers to remove the tags when
pull-request?  That's already allowed, to my understanding and some maintainers
are doing [1] today.   That can help preventing the git history of a subsystem
bloating or advertising priorietary companies, as much as the maintainer care.
Meanwhile, we can still get the information at review time, and also after
review from the mail archives.  It will still be handy as long as we use tools
like 'lei'.  As some maintainers are already removing the tags from the git
log, this may be anyway a better way.  Someone may interested in only their
subsystem history, but I find LLM users tend to contribute to multiple
subsystems, so this might actually matters.

It might be too clear to formally document this, though.

[1] https://lore.kernel.org/20260701115302.29c66401@kernel.org


Thanks,
SJ

[...]

  parent reply	other threads:[~2026-07-02 23:05 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 14:32 [PATCH] Documentation: remove the requirement for LLM attribution Jeff Layton
2026-07-02 14:53 ` Laurent Pinchart
2026-07-02 14:58   ` Lorenzo Stoakes
2026-07-02 15:02   ` Jeff Layton
2026-07-02 15:07     ` Lorenzo Stoakes
2026-07-02 14:57 ` Lorenzo Stoakes
2026-07-02 15:28   ` Laurent Pinchart
2026-07-02 15:36     ` Lorenzo Stoakes
2026-07-02 15:44       ` Laurent Pinchart
2026-07-02 15:07 ` Greg KH
2026-07-02 15:13   ` Jonathan Corbet
2026-07-02 15:20     ` Lorenzo Stoakes
2026-07-02 18:46     ` Andreas Dilger
2026-07-03  2:57       ` Theodore Tso
2026-07-03 11:50         ` Jori Koolstra
2026-07-03 16:12         ` Andreas Dilger
2026-07-02 15:15   ` Lorenzo Stoakes
2026-07-02 15:33   ` Jori Koolstra
2026-07-02 15:37     ` Lorenzo Stoakes
2026-07-02 15:36   ` Laurent Pinchart
2026-07-02 15:57   ` Jeff Layton
2026-07-02 16:13     ` Laurent Pinchart
2026-07-02 16:19       ` Greg KH
2026-07-02 16:32         ` Laurent Pinchart
2026-07-03  6:37           ` Greg KH
2026-07-03  7:23             ` David Hildenbrand (Arm)
2026-07-03  7:30               ` Greg KH
2026-07-03  7:33                 ` David Hildenbrand (Arm)
2026-07-03 11:42                 ` Theodore Tso
2026-07-03 11:53                   ` Laurent Pinchart
2026-07-03 12:04                   ` Jori Koolstra
2026-07-02 16:48         ` Jeff Layton
2026-07-02 16:50           ` Lorenzo Stoakes
2026-07-02 21:17             ` Boris Burkov
2026-07-02 23:17               ` SJ Park
2026-07-03  7:05               ` David Hildenbrand (Arm)
2026-07-03 13:12                 ` Lorenzo Stoakes
2026-07-03 16:32                   ` Laurent Pinchart
2026-07-03 18:22                     ` David Hildenbrand (Arm)
2026-07-03 18:26                   ` David Hildenbrand (Arm)
2026-07-02 23:05             ` SJ Park [this message]
2026-07-02 16:11 ` Chuck Lever
2026-07-02 16:14   ` Lorenzo Stoakes

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=20260702230540.98160-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bfoster@redhat.com \
    --cc=brauner@kernel.org \
    --cc=broonie@kernel.org \
    --cc=cem@kernel.org \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=ddiss@suse.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jani.nikula@intel.com \
    --cc=jkoolstra@xs4all.nl \
    --cc=jlayton@kernel.org \
    --cc=justinstitt@google.com \
    --cc=krzk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox