Message-ID: <d21ba8c1-2931-4133-bc82-5bdb670e4a69@intel.com>
Date: Thu, 13 Nov 2025 17:09:19 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: NeilBrown <neil@...wn.name>, Dave Hansen <dave.hansen@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
 Dan Williams <dan.j.williams@...el.com>, Theodore Ts'o <tytso@....edu>,
 Sasha Levin <sashal@...nel.org>, Jonathan Corbet <corbet@....net>,
 Kees Cook <kees@...nel.org>, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>, Miguel Ojeda <ojeda@...nel.org>,
 Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated
 content

On 11/11/25 15:45, NeilBrown wrote:
...
>> +Kernel contributors have been using tooling to generate contributions
>> +for a long time. These tools are constantly becoming more capable and
>> +undoubtedly improve developer productivity. At the same time, reviewer
>> +and maintainer bandwidth is a very scarce resource. Understanding
>> +which portions of a contribution come from humans versus tools is
>> +critical to maintain those resources and keep kernel development
>> +healthy.
> 
> "critical"?  Really?
> If I use "sed" to create a patch, it might be helpful for you to know
> that, but not critical.

I'll tone that down a bit.

> I also like the focus on "helping the reviewer".  That too is
> foundational.
> 
>   When submitting a patch you will benefit from efforts to build trust
>   with the maintainer, and anything you do to help the review process
>   run smoothly will help your patch get accepted.  Some guidelines for
>   how this applies with respect to tool-assisted patch creation, and LLM
>   (aka AI) in particular, are below.

To me, this veers a bit into a different area, which is explaining how
trust is important.

...>> + - Treat it just like any other contribution
>> + - Reject it outright
> 
> If I find that a maintainer might reject my tool-based submission
> outright, I might be tempted towards less transparency.
> I don't think we should legitimise this sort of response by listing it
> here.

I agree that this might steer an unscrupulous contributor into being
less transparent. But, I don't think this document is aimed at those
contributors in the first place.

They key question is whether maintainers in our project should have the
ability to reject a patch just because it was generated by a tool. I
think it would be silly for a maintainer to outright reject every bit of
content that was generated by a tool. But, it's equally silly to say
that maintainers should not have the ability to say that "tool $XYZ has
no place in the $ABC subsystem".

Maintainers can always say: "No". If they say it too much or for the
wrong reasons, we have a benevolent dictator for such situations.

>> + - Review the contribution with extra scrutiny
>> + - Suggest a better prompt instead of suggesting specific code changes
>> + - Ask for some other special steps, like asking the contributor to
>> +   elaborate on how the tool or model was trained
>> + - Ask the submitter to explain in more detail about the contribution
>> +   so that the maintainer can feel comfortable that the submitter fully
>> +   understands how the code works.
> 
> This last point contains an important idea that I think could be
> highlighted more.  The submitter needs to understand, and be able to
> defend, the submission; both its motivation and its content.
> "A tool generated the patch" is useful information but never an excuse
> for not understanding it.

This is fleshed out a bit more in v3. I hope you're able to take a look
at that when I post it as well.

Powered by blists - more mailing lists