Message-ID: <103ee61c-f958-440c-af73-1cf3600d10fd@intel.com>
Date: Mon, 10 Nov 2025 08:35:12 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 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/10/25 02:48, Lorenzo Stoakes wrote:
...
> It also seems slightly odd to produce this in advance of the maintainer's
> summit, as I felt there was some agreement that the topic should be discussed
> there?

The TAB discussions have been ongoing and this document was mostly put
together before the ksummit thread even launched off. This patch just
suffered from being put on the back burner.

> I think stating that we will NOT accept series that are generated without
> understanding would be very beneficial in all respects, rather than leaving
> it somehow implied.

I actually don't think that's a tooling-specific requirement.

If you're posting a series, you should understand it. I've seen quite a
few cases where folks will pick up someone else's work, forward port it,
and post it again without a clear understanding of the series.

"Understand and be able to defend what you contribute" is certainly a
good rule. It's also concise enough to have this document touch in it.

Would that suffice?

>> +Guidelines
>> +==========
>> +
>> +First, read the Developer's Certificate of Origin:
>> +Documentation/process/submitting-patches.rst . Its rules are simple
>> +and have been in place for a long time. They have covered many
>> +tool-generated contributions.
>> +
>> +Second, when making a contribution, be transparent about the origin of
>> +content in cover letters and changelogs. You can be more transparent
>> +by adding information like this:
>> +
>> + - What tools were used?
>> + - The input to the tools you used, like the coccinelle source script.
> 
> Not sure repeatedly using coccinelle as an example is helpful, as
> coccinelle is far less of an issue than LLM tooling, perhaps for the
> avoidance of doubt, expand this to include references to that?
> 
>> + - If code was largely generated from a single or short set of
>> +   prompts, include those prompts in the commit log. For longer
>> +   sessions, include a summary of the prompts and the nature of
>> +   resulting assistance.
> 
> Maybe worth saying send it in a cover letter if a series, but perhaps
> pedantic.

Do we have a good short term that means "commit logs or cover letter"?
"Changelogs" maybe? But, yeah, we don't want people reading this and
avoiding putting stuff in cover letters.

>> + - Which portions of the content were affected by that tool?
>> +
>> +As with all contributions, individual maintainers have discretion to
>> +choose how they handle the contribution. For example, they might:
>> +
>> + - Treat it just like any other contribution
>> + - Reject it outright
>> + - 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.
> 
> OK I wrote something suggesting you add this and you already have :) that's
> great. Let me go delete that request :)
> 
> However I'm not sure the 'as with all contributions' is right though - as a
> maintainer in mm I don't actually feel that we can reject outright without
> having to give significant explanation as to why.
> 
> And I think that's often the case - people (rightly) dislike blanket NAKs
> and it's a terrible practice, which often (also rightly) gets pushback from
> co-maintainers or others in the community.
> 
> So I think perhaps it'd also be useful to very explicitly say that
> maintainers may say no summarily in instances where the review load would
> simply be too much to handle large clearly-AI-generated and
> clearly-unfiltered series.
> 
> Another point to raise perhaps is that - even in the cases where the
> submitter is carefully reviewing generated output - that submitters must be
> reasonable in terms of the volume they submit. This is perhaps hand wavey
> but mentioning it would be great not least for the ability for maintainers
> to point at the doc and reference it.

How about we expand this bullet a bit?

- Review the contribution with extra scrutiny

to

- Treat the contribution specially like reviewing with extra scrutiny,
  or at a lower priority than human-generated content.

That's a good match for the "Treat it just like any other contribution"
bullet. Maintainers can either treat it normally _or_ specially.

>> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
>> index aa12f26601949..e1a8a31389f53 100644
>> --- a/Documentation/process/index.rst
>> +++ b/Documentation/process/index.rst
>> @@ -68,6 +68,7 @@ beyond).
>>     stable-kernel-rules
>>     management-style
>>     researcher-guidelines
>> +   generated-content
>>
>>  Dealing with bugs
>>  -----------------
> 
> I guess this is a WIP?

Powered by blists - more mailing lists