Re: LLM disclosure (was: [PATCH v2] vfs: remove the excl argument from the ->create() inode_operation)

[NeilBrown <neilb@ownmail.net>]

On Sat, 08 Nov 2025, Jeff Layton wrote:
> On Fri, 2025-11-07 at 15:35 -0700, Jonathan Corbet wrote:
> > NeilBrown <neilb@ownmail.net> writes:
> > 
> > > On Sat, 08 Nov 2025, Jeff Layton wrote:
> > 
> > > > Full disclosure: I did use Claude code to generate the first
> > > > approximation of this patch, but I had to fix a number of things that it
> > > > missed.  I probably could have given it better prompts. In any case, I'm
> > > > not sure how to properly attribute this (or if I even need to).
> > > 
> > > My understanding is that if you fully understand (and can defend) the
> > > code change with all its motivations and implications as well as if you
> > > had written it yourself, then you don't need to attribute whatever fancy
> > > text editor or IDE (e.g.  Claude) that you used to help produce the
> > > patch.
> > 
> > The proposed policy for such things is here, under review right now:
> > 
> >   https://lore.kernel.org/all/20251105231514.3167738-1-dave.hansen@linux.intel.com/
> > 
> > jon
> 
> Thanks Jon.
> 
> I'm guessing that this would fall under the "menial task"
> classification, and therefore doesn't need attribution. This seems
> applicable:
> 
> + - Purely mechanical transformations like variable renaming
> 
> This is a little different, but it's a similar rote task.
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

The bit I particularly liked was:

+
+Even if your tool use is out of scope you should still always consider
+if it would help reviewing your contribution if the reviewer knows
+about the tool that you used.
+

"would it help the reviewer"?  I agree that is a key question.  In your
case I cannot see how it would help.

Thanks,
NeilBrown