All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Lorenzo Stoakes <ljs@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>,
	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 18:44:56 +0300	[thread overview]
Message-ID: <20260702154456.GB3562985@killaraus.ideasonboard.com> (raw)
In-Reply-To: <akaEcP2E7xYsIAqW@lucifer>

On Thu, Jul 02, 2026 at 04:36:20PM +0100, Lorenzo Stoakes wrote:
> On Thu, Jul 02, 2026 at 06:28:15PM +0300, Laurent Pinchart wrote:
> > Hi Lorenzo,
> >
> > On Thu, Jul 02, 2026 at 03:57:11PM +0100, Lorenzo Stoakes wrote:
> > > I'm a little surprised I'm cc'd on this :) I'm not entirely sure if my pushing
> > > back on this is going to mean anything but I suppose here goes nothing.
> > >
> > > 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.
> > >
> > > Does something not being universally followed therefore make it worthless?
> > >
> > > You really have to explain that, because this is literally true of any rule
> > > whatsoever we might have in the kernel, should we drop all of them?
> > >
> > > I think you should replace this with a cogent argument such as that you feel it
> > > is not being used in the _majority_ of cases or is very rarely used, and that
> > > value is in your view not there.
> > >
> > > >
> > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > >
> > > I agree with this point, we should drop the model.
> > >
> > > > 3/ It's not clear why we want to collect this info in the first place.
> > >
> > > Well I made arguments on the other thread, but to repeat:
> > >
> > > - It makes it easier to engage with people when they do ack it.
> > >
> > > - It makes it far quicker to be able to do so.
> > >
> > > - There's a barrier to mentioning an LLM if it's not provided - people can get
> > >   upset, or it can cause issues to raise it as a concern.
> > >
> > > - Even if it's only there in _some_ cases, it makes _those_ cases easier to deal
> > >   with.
> >
> > As far as I understand, all the above arguments would also be addressed
> > with either a free-formed mention of LLM usage, or a formal
> > "non-advertising" tag that is not merged in the kernel history, right ?
> 
> Well I prefer a tag for reasons below. I'm fine with non-advertising yeah.
> 
> > > - It provides some (incomplete) data that might make it easier to deal with
> > >   bug-causing patches.
> > >
> > > - It provides some (incomplete) data on bug rates with/without LLMs.
> >
> > For those two I suppose a machine-parseable tag in the git history could
> > improve things slightly compared to information provided in the patch
> > submission that would not get recorded in the history.
> 
> Yeah, again I could live without it being in the tree. I think there's some
> advantages though.
> 
> See below for tag argument.
> 
> > Is this why you have a preference for a formal tag compared to a
> > free-formed mention ?
> >
> > > I do agree they're far far less useful when there's not some indication of how
> > > much of the patch was LLM-generated.
> > >
> > > Their usefulness is obviously deeply far from perfect, but not zero.
> > >
> > > > Given that the data this provides is flawed at best and is being
> > > > collected for a purpose that isn't clear, let's just kill the
> > > > requirement for these tags from the kernel at large.
> > >
> > > I feel there are purposes. Perhaps the argument is stronger for having the tags
> > > on submissions rather than actually in-tree, however.
> >
> > I really think we need to have the information at submission. I think I
> > have a slight preference for not recording it in the kernel tree, but
> > only slight.
> 
> It seems we are more in agreement than it seems :)

I knew we were :-)

> I prefer a tag as it's clear cut and easily greppable and easily noticeable.
> 
> If it's words it can be vague or be unclear or inconsistent and you might miss
> etc.
> 
> So I have a strong preference for a tag, would love to add details about how
> much LLM done (that'll be vague obviously + have grey lines).

I have a slight preference for not recording that in the git history,
but I can live with either.

> I agree gettig rid of model is worthwhile but I'm not bothered if we don't do
> that.

There I have a very strong preference for stopping free advertising.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2026-07-02 15:45 UTC|newest]

Thread overview: 44+ 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 [this message]
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-06  8:44                   ` Mauro Carvalho Chehab
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
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=20260702154456.GB3562985@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --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=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=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 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.