In the last few years, the capabilities of coding tools have exploded.
As those capabilities have expanded, contributors and maintainers have
more and more questions about how and when to apply those
capabilities.

Add new Documentation to guide contributors on how to best use kernel
development tools, new and old.

Note, though, there are fundamentally no new or unique rules in this
new document. It clarifies expectations that the kernel community has
had for many years. For example, researchers are already asked to
disclose the tools they use to find issues by
Documentation/process/researcher-guidelines.rst. This new document
just reiterates existing best practices for development tooling.

In short: Please show your work and make sure your contribution is
easy to review.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Shuah Khan <shuah@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: SeongJae Park <sj@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Cc: NeilBrown <neilb@ownmail.net>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: workflows@vger.kernel.org
Cc: ksummit@lists.linux.dev
Link: https://lore.kernel.org/all/cfb8bb96-e798-474d-bc6f-9cf610fe720f@lucifer.local/

--

Changes from v4:
 * Modest tweaking and rewording to strengthen language
 * Add a section to help alleviate concerns that the document would
   not enable maintainers to act forcefully enough in the face of
   high-volume low-quality contributions (aka. AI slop).
   This is very close to some text that Lorenzo posted. I just
   made some very minor wording tweaks and spelling fixes.
 * Note: v4 mistakenly had "v3" in the subject

Changes from v3:
 * Wording/formatting tweaks (Randy)

Changes from v2:
 * Mention testing (Shuah)
 * Remove "very", rename LLM => coding assistant (Dan)
 * More formatting sprucing up and minor typos (Miguel)
 * Make changelog and text less flashy (Christian)
 * Tone down critical=>helpful (Neil)

Changes from v1:
 * Rename to generated-content.rst and add to documentation index.
   (Jon)
 * Rework subject to align with the new filename
 * Replace commercial names with generic ones. (Jon)
 * Be consistent about punctuation at the end of bullets for whole
   sentences. (Miguel)
 * Formatting sprucing up and minor typos (Miguel)

This document was a collaborative effort from all the members of
the TAB. I just reformatted it into .rst and wrote the changelog.
---
 Documentation/process/generated-content.rst | 108 ++++++++++++++++++++
 Documentation/process/index.rst             |   1 +
 2 files changed, 109 insertions(+)
 create mode 100644 Documentation/process/generated-content.rst

diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
new file mode 100644
index 000000000000..867bf8894289
--- /dev/null
+++ b/Documentation/process/generated-content.rst
@@ -0,0 +1,108 @@
+============================================
+Kernel Guidelines for Tool-Generated Content
+============================================
+
+Purpose
+=======
+
+Kernel contributors have been using tooling to generate contributions
+for a long time. These tools can increase the volume of contributions.
+At the same time, reviewer and maintainer bandwidth is a scarce
+resource. Understanding which portions of a contribution come from
+humans versus tools is helpful to maintain those resources and keep
+kernel development healthy.
+
+The goal here is to clarify community expectations around tools. This
+lets everyone become more productive while also maintaining high
+degrees of trust between submitters and reviewers.
+
+Out of Scope
+============
+
+These guidelines do not apply to tools that make trivial tweaks to
+preexisting content. Nor do they pertain to AI tooling that helps with
+menial tasks. Some examples:
+
+ - Spelling and grammar fix ups, like rephrasing to imperative voice
+ - Typing aids like identifier completion, common boilerplate or
+   trivial pattern completion
+ - Purely mechanical transformations like variable renaming
+ - Reformatting, like running Lindent, ``clang-format`` or
+   ``rust-fmt``
+
+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.
+
+In Scope
+========
+
+These guidelines apply when a meaningful amount of content in a kernel
+contribution was not written by a person in the Signed-off-by chain,
+but was instead created by a tool.
+
+Detection of a problem and testing the fix for it is also part of the
+development process; if a tool was used to find a problem addressed by
+a change, that should be noted in the changelog. This not only gives
+credit where it is due, it also helps fellow developers find out about
+these tools.
+
+Some examples:
+ - Any tool-suggested fix such as ``checkpatch.pl --fix``
+ - Coccinelle scripts
+ - A chatbot generated a new function in your patch to sort list entries.
+ - A .c file in the patch was originally generated by a coding
+   assistant but cleaned up by hand.
+ - The changelog was generated by handing the patch to a generative AI
+   tool and asking it to write the changelog.
+ - The changelog was translated from another language.
+
+If in doubt, choose transparency and assume these guidelines apply to
+your contribution.
+
+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. Ensure that you understand your entire
+submission and are prepared to respond to review comments.
+
+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.
+ - If code was largely generated from a single or short set of
+   prompts, include those prompts. For longer sessions, include a
+   summary of the prompts and the nature of resulting assistance.
+ - Which portions of the content were affected by that tool?
+ - How is the submission tested and what tools were used to test the
+   fix?
+
+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.
+ - Treat the contribution specially like reviewing with extra scrutiny,
+   or at a lower priority than human-generated content.
+ - 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 be assured that the submitter fully
+   understands how the code works.
+
+If tools permit you to generate a contribution automatically, expect
+additional scrutiny in proportion to how much of it was generated.
+
+As with the output of any tooling, the result may be incorrect or
+inappropriate. You are expected to understand and to be able to defend
+everything you submit. If you are unable to do so, then do not submit
+the resulting changes.
+
+If you do so anyway, maintainers are entitled to reject your series
+without detailed review.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index aa12f2660194..e1a8a31389f5 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
 -----------------
-- 
2.34.1

Dave Hansen <dave.hansen@linux.intel.com> writes:

> In the last few years, the capabilities of coding tools have exploded.
> As those capabilities have expanded, contributors and maintainers have
> more and more questions about how and when to apply those
> capabilities.
>
> Add new Documentation to guide contributors on how to best use kernel
> development tools, new and old.

So, in substance, this seems fine to me.

Naturally I have some nits I'll point out below.  But if you're tired of
this I'm happy to apply this version as well, let me know.

For the record, going forward, I'm likely to treat proposed changes to
this file the way I do coding-style.rst - I'll be highly reluctant to
apply them without a strong sense of community consensus behind them.

[...]

> diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
> new file mode 100644
> index 000000000000..867bf8894289
> --- /dev/null
> +++ b/Documentation/process/generated-content.rst
> @@ -0,0 +1,108 @@
> +============================================
> +Kernel Guidelines for Tool-Generated Content
> +============================================
> +
> +Purpose
> +=======
> +
> +Kernel contributors have been using tooling to generate contributions
> +for a long time. These tools can increase the volume of contributions.
> +At the same time, reviewer and maintainer bandwidth is a scarce
> +resource. Understanding which portions of a contribution come from
> +humans versus tools is helpful to maintain those resources and keep
> +kernel development healthy.
> +
> +The goal here is to clarify community expectations around tools. This
> +lets everyone become more productive while also maintaining high
> +degrees of trust between submitters and reviewers.
> +
> +Out of Scope
> +============
> +
> +These guidelines do not apply to tools that make trivial tweaks to
> +preexisting content. Nor do they pertain to AI tooling that helps with

It seems you have gone out of your way to avoid using "AI" and refer to
"tooling" in general, so it's a bit strange to see that term here,
especially at the head of a list of mostly non-AI tasks.

> +menial tasks. Some examples:
> +
> + - Spelling and grammar fix ups, like rephrasing to imperative voice
> + - Typing aids like identifier completion, common boilerplate or
> +   trivial pattern completion
> + - Purely mechanical transformations like variable renaming
> + - Reformatting, like running Lindent, ``clang-format`` or
> +   ``rust-fmt``
> +
> +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

s/if/whether/

> +about the tool that you used.
> +
> +In Scope
> +========
> +
> +These guidelines apply when a meaningful amount of content in a kernel
> +contribution was not written by a person in the Signed-off-by chain,
> +but was instead created by a tool.
> +
> +Detection of a problem and testing the fix for it is also part of the
> +development process; if a tool was used to find a problem addressed by
> +a change, that should be noted in the changelog. This not only gives
> +credit where it is due, it also helps fellow developers find out about
> +these tools.
> +
> +Some examples:
> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
> + - Coccinelle scripts
> + - A chatbot generated a new function in your patch to sort list entries.
> + - A .c file in the patch was originally generated by a coding
> +   assistant but cleaned up by hand.
> + - The changelog was generated by handing the patch to a generative AI
> +   tool and asking it to write the changelog.
> + - The changelog was translated from another language.
> +
> +If in doubt, choose transparency and assume these guidelines apply to
> +your contribution.
> +
> +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. Ensure that you understand your entire
> +submission and are prepared to respond to review comments.
> +
> +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.
> + - If code was largely generated from a single or short set of
> +   prompts, include those prompts. For longer sessions, include a
> +   summary of the prompts and the nature of resulting assistance.
> + - Which portions of the content were affected by that tool?
> + - How is the submission tested and what tools were used to test the
> +   fix?
> +
> +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.
> + - Treat the contribution specially like reviewing with extra scrutiny,

s/ like/, for example,/

> +   or at a lower priority than human-generated content.
> + - 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 be assured that the submitter fully
> +   understands how the code works.
> +
> +If tools permit you to generate a contribution automatically, expect
> +additional scrutiny in proportion to how much of it was generated.
> +
> +As with the output of any tooling, the result may be incorrect or
> +inappropriate. You are expected to understand and to be able to defend
> +everything you submit. If you are unable to do so, then do not submit
> +the resulting changes.
> +
> +If you do so anyway, maintainers are entitled to reject your series
> +without detailed review.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index aa12f2660194..e1a8a31389f5 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

At some point, $SOMEBODY should probably add a brief reference to
submitting-patches.rst as well.

Thanks,

jon

On 1/13/26 11:22, Jonathan Corbet wrote:
>> --- a/Documentation/process/index.rst
>> +++ b/Documentation/process/index.rst
>> @@ -68,6 +68,7 @@ beyond).
>>     stable-kernel-rules
>>     management-style
>>     researcher-guidelines
>> +   generated-content
> At some point, $SOMEBODY should probably add a brief reference to
> submitting-patches.rst as well.

I can definitely send a follow-up for that.

It has a "Tooling" section. But it also seems like a sentence at the
top, like:

...
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -15,6 +15,8 @@ Documentation/process/submit-checklist.rst
 for a list of items to check before submitting code.
 For device tree binding patches, read
 Documentation/devicetree/bindings/submitting-patches.rst.
+If you used tools to generate part of your contribution, read
+Documentation/process/generated-content.rst.
 
 This documentation assumes that you're using ``git`` to prepare your patches.
 If you're unfamiliar with ``git``, you would be well-advised to learn how to

might also be appropriate.

Any preferences?

On Mon, 12 Jan 2026, Dave Hansen wrote:

> In the last few years, the capabilities of coding tools have exploded.
> As those capabilities have expanded, contributors and maintainers have
> more and more questions about how and when to apply those
> capabilities.
> 
> Add new Documentation to guide contributors on how to best use kernel
> development tools, new and old.
> 
> Note, though, there are fundamentally no new or unique rules in this
> new document. It clarifies expectations that the kernel community has
> had for many years. For example, researchers are already asked to
> disclose the tools they use to find issues by
> Documentation/process/researcher-guidelines.rst. This new document
> just reiterates existing best practices for development tooling.
> 
> In short: Please show your work and make sure your contribution is
> easy to review.
> 
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Shuah Khan <shuah@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> Reviewed-by: SeongJae Park <sj@kernel.org>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Reviewed-by: Simon Glass <simon.glass@canonical.com>

The premise of the document is good.  I offered a couple of suggestions;
however, even if they aren't accepted, the document LGTM.

Reviewed-by: Lee Jones <lee@kernel.org>

> Cc: NeilBrown <neilb@ownmail.net>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: workflows@vger.kernel.org
> Cc: ksummit@lists.linux.dev
> Link: https://lore.kernel.org/all/cfb8bb96-e798-474d-bc6f-9cf610fe720f@lucifer.local/
> 
> --
> 
> Changes from v4:
>  * Modest tweaking and rewording to strengthen language
>  * Add a section to help alleviate concerns that the document would
>    not enable maintainers to act forcefully enough in the face of
>    high-volume low-quality contributions (aka. AI slop).
>    This is very close to some text that Lorenzo posted. I just
>    made some very minor wording tweaks and spelling fixes.
>  * Note: v4 mistakenly had "v3" in the subject
> 
> Changes from v3:
>  * Wording/formatting tweaks (Randy)
> 
> Changes from v2:
>  * Mention testing (Shuah)
>  * Remove "very", rename LLM => coding assistant (Dan)
>  * More formatting sprucing up and minor typos (Miguel)
>  * Make changelog and text less flashy (Christian)
>  * Tone down critical=>helpful (Neil)
> 
> Changes from v1:
>  * Rename to generated-content.rst and add to documentation index.
>    (Jon)
>  * Rework subject to align with the new filename
>  * Replace commercial names with generic ones. (Jon)
>  * Be consistent about punctuation at the end of bullets for whole
>    sentences. (Miguel)
>  * Formatting sprucing up and minor typos (Miguel)
> 
> This document was a collaborative effort from all the members of
> the TAB. I just reformatted it into .rst and wrote the changelog.
> ---
>  Documentation/process/generated-content.rst | 108 ++++++++++++++++++++
>  Documentation/process/index.rst             |   1 +
>  2 files changed, 109 insertions(+)
>  create mode 100644 Documentation/process/generated-content.rst
> 
> diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
> new file mode 100644
> index 000000000000..867bf8894289
> --- /dev/null
> +++ b/Documentation/process/generated-content.rst
> @@ -0,0 +1,108 @@
> +============================================
> +Kernel Guidelines for Tool-Generated Content
> +============================================
> +
> +Purpose
> +=======
> +
> +Kernel contributors have been using tooling to generate contributions
> +for a long time. These tools can increase the volume of contributions.
> +At the same time, reviewer and maintainer bandwidth is a scarce
> +resource. Understanding which portions of a contribution come from
> +humans versus tools is helpful to maintain those resources and keep
> +kernel development healthy.
> +
> +The goal here is to clarify community expectations around tools. This
> +lets everyone become more productive while also maintaining high
> +degrees of trust between submitters and reviewers.
> +
> +Out of Scope
> +============
> +
> +These guidelines do not apply to tools that make trivial tweaks to
> +preexisting content. Nor do they pertain to AI tooling that helps with
> +menial tasks. Some examples:
> +
> + - Spelling and grammar fix ups, like rephrasing to imperative voice
> + - Typing aids like identifier completion, common boilerplate or
> +   trivial pattern completion
> + - Purely mechanical transformations like variable renaming
> + - Reformatting, like running Lindent, ``clang-format`` or
> +   ``rust-fmt``
> +
> +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.

Parsing ... okay, that took a few goes.  How about:

  Even if disclosure of your tool isn't mandated, providing this context
  often helps reviewers evaluate your contribution more effectively.
  Clear documentation of your workflow ensures a faster review with less
  contention.

> +In Scope
> +========
> +
> +These guidelines apply when a meaningful amount of content in a kernel
> +contribution was not written by a person in the Signed-off-by chain,
> +but was instead created by a tool.
> +
> +Detection of a problem and testing the fix for it is also part of the
> +development process; if a tool was used to find a problem addressed by
> +a change, that should be noted in the changelog. This not only gives
> +credit where it is due, it also helps fellow developers find out about
> +these tools.
> +
> +Some examples:
> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
> + - Coccinelle scripts
> + - A chatbot generated a new function in your patch to sort list entries.
> + - A .c file in the patch was originally generated by a coding
> +   assistant but cleaned up by hand.
> + - The changelog was generated by handing the patch to a generative AI
> +   tool and asking it to write the changelog.
> + - The changelog was translated from another language.

Nit: Suggest removing the sporadic use of full-stops (periods) across all lists.

Or add them everywhere - so long as it's consistent.

> +If in doubt, choose transparency and assume these guidelines apply to
> +your contribution.
> +
> +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. Ensure that you understand your entire
> +submission and are prepared to respond to review comments.
> +
> +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.
> + - If code was largely generated from a single or short set of
> +   prompts, include those prompts. For longer sessions, include a
> +   summary of the prompts and the nature of resulting assistance.
> + - Which portions of the content were affected by that tool?
> + - How is the submission tested and what tools were used to test the
> +   fix?
> +
> +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.
> + - Treat the contribution specially like reviewing with extra scrutiny,
> +   or at a lower priority than human-generated content.
> + - 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 be assured that the submitter fully
> +   understands how the code works.
> +
> +If tools permit you to generate a contribution automatically, expect
> +additional scrutiny in proportion to how much of it was generated.
> +
> +As with the output of any tooling, the result may be incorrect or
> +inappropriate. You are expected to understand and to be able to defend
> +everything you submit. If you are unable to do so, then do not submit
> +the resulting changes.
> +
> +If you do so anyway, maintainers are entitled to reject your series
> +without detailed review.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index aa12f2660194..e1a8a31389f5 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
>  -----------------
> -- 
> 2.34.1
> 
> 

-- 
Lee Jones [李琼斯]

On 1/13/26 02:36, Lee Jones wrote:
...
>> +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.
> 
> Parsing ... okay, that took a few goes.  How about:
> 
>   Even if disclosure of your tool isn't mandated, providing this context
>   often helps reviewers evaluate your contribution more effectively.
>   Clear documentation of your workflow ensures a faster review with less
>   contention.
I agree that the sentence is hard to parse. But, I want to explicitly
say "out of scope" to tie this in to the rest of the section. How about
this?

	Even if your tool use is out of scope, consider disclosing how
	you used the tool. Clear documentation of your workflow often
	helps reviewers do their jobs more efficiently.

BTW, I do think we're well into diminishing returns territory. I'll roll
this into a v6 if there's a v6. But, if it's pulled in as-is, I think
the original can stay without causing too much harm.

...>> +Some examples:
>> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
>> + - Coccinelle scripts
>> + - A chatbot generated a new function in your patch to sort list entries.
>> + - A .c file in the patch was originally generated by a coding
>> +   assistant but cleaned up by hand.
>> + - The changelog was generated by handing the patch to a generative AI
>> +   tool and asking it to write the changelog.
>> + - The changelog was translated from another language.
> 
> Nit: Suggest removing the sporadic use of full-stops (periods) across all lists.
> 
> Or add them everywhere - so long as it's consistent.

The rule that I read is that when the bullets are full, complete
sentences, you should use periods. When they are just nouns or shards of
sentences, leave off the periods.

I _think_ that's the consensus for how to punctuate bulleted list items.

But I don't remember where I read that, if it was in Documentation/
somewhere or it was some random rule on the Internet I decided to apply.

On Tue, 13 Jan 2026, Dave Hansen wrote:

> On 1/13/26 02:36, Lee Jones wrote:
> ...
> >> +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.
> > 
> > Parsing ... okay, that took a few goes.  How about:
> > 
> >   Even if disclosure of your tool isn't mandated, providing this context
> >   often helps reviewers evaluate your contribution more effectively.
> >   Clear documentation of your workflow ensures a faster review with less
> >   contention.
> I agree that the sentence is hard to parse. But, I want to explicitly
> say "out of scope" to tie this in to the rest of the section. How about
> this?
> 
> 	Even if your tool use is out of scope, consider disclosing how
> 	you used the tool. Clear documentation of your workflow often
> 	helps reviewers do their jobs more efficiently.
> 
> BTW, I do think we're well into diminishing returns territory. I'll roll
> this into a v6 if there's a v6. But, if it's pulled in as-is, I think
> the original can stay without causing too much harm.

Agree.  Thanks for considering.

> ...>> +Some examples:
> >> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
> >> + - Coccinelle scripts
> >> + - A chatbot generated a new function in your patch to sort list entries.
> >> + - A .c file in the patch was originally generated by a coding
> >> +   assistant but cleaned up by hand.
> >> + - The changelog was generated by handing the patch to a generative AI
> >> +   tool and asking it to write the changelog.
> >> + - The changelog was translated from another language.
> > 
> > Nit: Suggest removing the sporadic use of full-stops (periods) across all lists.
> > 
> > Or add them everywhere - so long as it's consistent.
> 
> The rule that I read is that when the bullets are full, complete
> sentences, you should use periods. When they are just nouns or shards of
> sentences, leave off the periods.
> 
> I _think_ that's the consensus for how to punctuate bulleted list items.
> 
> But I don't remember where I read that, if it was in Documentation/
> somewhere or it was some random rule on the Internet I decided to apply.

The non-consistency of it makes me twitch, but perhaps just my issue.

-- 
Lee Jones [李琼斯]

On Tue, 13 Jan 2026 at 19:05, Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 1/13/26 02:36, Lee Jones wrote:
> ...
> >> +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.
> >
> > Parsing ... okay, that took a few goes.  How about:
> >
> >   Even if disclosure of your tool isn't mandated, providing this context
> >   often helps reviewers evaluate your contribution more effectively.
> >   Clear documentation of your workflow ensures a faster review with less
> >   contention.
> I agree that the sentence is hard to parse. But, I want to explicitly
> say "out of scope" to tie this in to the rest of the section. How about
> this?
>
>         Even if your tool use is out of scope, consider disclosing how
>         you used the tool. Clear documentation of your workflow often
>         helps reviewers do their jobs more efficiently.
>
> BTW, I do think we're well into diminishing returns territory. I'll roll
> this into a v6 if there's a v6. But, if it's pulled in as-is, I think
> the original can stay without causing too much harm.
>
> ...>> +Some examples:
> >> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
> >> + - Coccinelle scripts
> >> + - A chatbot generated a new function in your patch to sort list entries.
> >> + - A .c file in the patch was originally generated by a coding
> >> +   assistant but cleaned up by hand.
> >> + - The changelog was generated by handing the patch to a generative AI
> >> +   tool and asking it to write the changelog.
> >> + - The changelog was translated from another language.
> >
> > Nit: Suggest removing the sporadic use of full-stops (periods) across all lists.
> >
> > Or add them everywhere - so long as it's consistent.
>
> The rule that I read is that when the bullets are full, complete
> sentences, you should use periods. When they are just nouns or shards of
> sentences, leave off the periods.

Or for the latter: use commas for all but the last one, and finish
with a period.

Just my 0.02€, from an old LaTeX user...

P.S. Linus seems to disagree, as he consistently drops the carefully
     placed commas and periods when merging my pull requests...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Mon, Jan 12, 2026 at 04:06:12PM -0800, Dave Hansen wrote:
> In the last few years, the capabilities of coding tools have exploded.
> As those capabilities have expanded, contributors and maintainers have
> more and more questions about how and when to apply those
> capabilities.
>
> Add new Documentation to guide contributors on how to best use kernel
> development tools, new and old.
>
> Note, though, there are fundamentally no new or unique rules in this
> new document. It clarifies expectations that the kernel community has
> had for many years. For example, researchers are already asked to
> disclose the tools they use to find issues by
> Documentation/process/researcher-guidelines.rst. This new document
> just reiterates existing best practices for development tooling.
>
> In short: Please show your work and make sure your contribution is
> easy to review.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>

LGTM, thanks for adding my bit :) So:

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> Reviewed-by: Shuah Khan <shuah@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> Reviewed-by: SeongJae Park <sj@kernel.org>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Reviewed-by: Simon Glass <simon.glass@canonical.com>
> Cc: NeilBrown <neilb@ownmail.net>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: workflows@vger.kernel.org
> Cc: ksummit@lists.linux.dev
> Link: https://lore.kernel.org/all/cfb8bb96-e798-474d-bc6f-9cf610fe720f@lucifer.local/
>
> --
>
> Changes from v4:
>  * Modest tweaking and rewording to strengthen language
>  * Add a section to help alleviate concerns that the document would
>    not enable maintainers to act forcefully enough in the face of
>    high-volume low-quality contributions (aka. AI slop).
>    This is very close to some text that Lorenzo posted. I just
>    made some very minor wording tweaks and spelling fixes.
>  * Note: v4 mistakenly had "v3" in the subject
>
> Changes from v3:
>  * Wording/formatting tweaks (Randy)
>
> Changes from v2:
>  * Mention testing (Shuah)
>  * Remove "very", rename LLM => coding assistant (Dan)
>  * More formatting sprucing up and minor typos (Miguel)
>  * Make changelog and text less flashy (Christian)
>  * Tone down critical=>helpful (Neil)
>
> Changes from v1:
>  * Rename to generated-content.rst and add to documentation index.
>    (Jon)
>  * Rework subject to align with the new filename
>  * Replace commercial names with generic ones. (Jon)
>  * Be consistent about punctuation at the end of bullets for whole
>    sentences. (Miguel)
>  * Formatting sprucing up and minor typos (Miguel)
>
> This document was a collaborative effort from all the members of
> the TAB. I just reformatted it into .rst and wrote the changelog.
> ---
>  Documentation/process/generated-content.rst | 108 ++++++++++++++++++++
>  Documentation/process/index.rst             |   1 +
>  2 files changed, 109 insertions(+)
>  create mode 100644 Documentation/process/generated-content.rst
>
> diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
> new file mode 100644
> index 000000000000..867bf8894289
> --- /dev/null
> +++ b/Documentation/process/generated-content.rst
> @@ -0,0 +1,108 @@
> +============================================
> +Kernel Guidelines for Tool-Generated Content
> +============================================
> +
> +Purpose
> +=======
> +
> +Kernel contributors have been using tooling to generate contributions
> +for a long time. These tools can increase the volume of contributions.
> +At the same time, reviewer and maintainer bandwidth is a scarce
> +resource. Understanding which portions of a contribution come from
> +humans versus tools is helpful to maintain those resources and keep
> +kernel development healthy.
> +
> +The goal here is to clarify community expectations around tools. This
> +lets everyone become more productive while also maintaining high
> +degrees of trust between submitters and reviewers.
> +
> +Out of Scope
> +============
> +
> +These guidelines do not apply to tools that make trivial tweaks to
> +preexisting content. Nor do they pertain to AI tooling that helps with
> +menial tasks. Some examples:
> +
> + - Spelling and grammar fix ups, like rephrasing to imperative voice
> + - Typing aids like identifier completion, common boilerplate or
> +   trivial pattern completion
> + - Purely mechanical transformations like variable renaming
> + - Reformatting, like running Lindent, ``clang-format`` or
> +   ``rust-fmt``
> +
> +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.
> +
> +In Scope
> +========
> +
> +These guidelines apply when a meaningful amount of content in a kernel
> +contribution was not written by a person in the Signed-off-by chain,
> +but was instead created by a tool.
> +
> +Detection of a problem and testing the fix for it is also part of the
> +development process; if a tool was used to find a problem addressed by
> +a change, that should be noted in the changelog. This not only gives
> +credit where it is due, it also helps fellow developers find out about
> +these tools.
> +
> +Some examples:
> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
> + - Coccinelle scripts
> + - A chatbot generated a new function in your patch to sort list entries.
> + - A .c file in the patch was originally generated by a coding
> +   assistant but cleaned up by hand.
> + - The changelog was generated by handing the patch to a generative AI
> +   tool and asking it to write the changelog.
> + - The changelog was translated from another language.
> +
> +If in doubt, choose transparency and assume these guidelines apply to
> +your contribution.
> +
> +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. Ensure that you understand your entire
> +submission and are prepared to respond to review comments.
> +
> +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.
> + - If code was largely generated from a single or short set of
> +   prompts, include those prompts. For longer sessions, include a
> +   summary of the prompts and the nature of resulting assistance.
> + - Which portions of the content were affected by that tool?
> + - How is the submission tested and what tools were used to test the
> +   fix?
> +
> +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.
> + - Treat the contribution specially like reviewing with extra scrutiny,
> +   or at a lower priority than human-generated content.
> + - 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 be assured that the submitter fully
> +   understands how the code works.
> +
> +If tools permit you to generate a contribution automatically, expect
> +additional scrutiny in proportion to how much of it was generated.
> +
> +As with the output of any tooling, the result may be incorrect or
> +inappropriate. You are expected to understand and to be able to defend
> +everything you submit. If you are unable to do so, then do not submit
> +the resulting changes.
> +
> +If you do so anyway, maintainers are entitled to reject your series
> +without detailed review.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index aa12f2660194..e1a8a31389f5 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
>  -----------------
> --
> 2.34.1
>

On Mon, Jan 12, 2026 at 04:06:12PM -0800, Dave Hansen wrote:
> +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.
> + - Treat the contribution specially like reviewing with extra scrutiny,
> +   or at a lower priority than human-generated content.
> + - 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 be assured that the submitter fully
> +   understands how the code works.
> +
> +If tools permit you to generate a contribution automatically, expect
> +additional scrutiny in proportion to how much of it was generated.
> +
> +As with the output of any tooling, the result may be incorrect or
> +inappropriate. You are expected to understand and to be able to defend
> +everything you submit. If you are unable to do so, then do not submit
> +the resulting changes.
> +
> +If you do so anyway, maintainers are entitled to reject your series
> +without detailed review.

Argh... Flip.  In context, that sounds even more sinister and
threatening than my over the top proposal.  We have to "defend"
everything?  "If you do so anyway" sounds like we're jumping to a
"per my last email" from the get go.  What about:

If tools permit you to generate a contribution automatically, expect
additional scrutiny in proportion to how much of it was generated.

Every kernel patch needs careful review from multiple people.  Please,
don't start the public review process until after you have carefully
reviewed the patches yourself.  If you don't have the necessary
expertise to review kernel code, consider asking for help first before
sending them to the main list.

Ideally, patches would be tested but we understand that that's not
always possible.  Be transparent about how confident we can be that the
changes don't introduce new problems and how they have been tested.

Bug reports especially are very welcome.  Bug reports are more likely
to be dealt with if they can be tied to the individual commit which
introduced them.  With new kinds of warnings, it is better to send
a few at a time at the start to see if they are a real issue or how
they can be improved.

regards,
dan carpenter

Dan Carpenter wrote:
[..]
> If tools permit you to generate a contribution automatically, expect
> additional scrutiny in proportion to how much of it was generated.
> 
> Every kernel patch needs careful review from multiple people.  Please,
> don't start the public review process until after you have carefully
> reviewed the patches yourself.  If you don't have the necessary
> expertise to review kernel code, consider asking for help first before
> sending them to the main list.

Note, I do not want additional changes to this document, my Reviewed-by
still stands with this version, it is good, ship it.

However, I do want to endorse this sentiment as uniquely capturing a
truism of kernel development that perhaps belongs in
Documentation/process/submitting-patches.rst. It captures it in a way
that avoids the conceit of the "slop is special" argument.

Contributions are accepted in large part based in trust in the author.
So much so that even long time contributors self censor, self mistrust,
based on the adage "debugging is harder than developing, if you develop
at the limits of your cleverness you will not be able to debug the
result." Tools potentially allow you to develop beyond the limits of
your own cleverness which implicates the result as "undebuggable" and
unmaintainable.

So a simple rule of "generally you should be able to demonstrate the
ability to substantively review a contribution of similar complexity
before expecting the kernel community to engage in earnest" mitigates
the asymmetric threat of AI contributions *and* contributors that have
not built-up enough trust capital with their upstream maintainer.

On Tue, Jan 13, 2026 at 10:20:44AM -0800, dan.j.williams@intel.com wrote:
>Dan Carpenter wrote:
>[..]
>> If tools permit you to generate a contribution automatically, expect
>> additional scrutiny in proportion to how much of it was generated.
>>
>> Every kernel patch needs careful review from multiple people.  Please,
>> don't start the public review process until after you have carefully
>> reviewed the patches yourself.  If you don't have the necessary
>> expertise to review kernel code, consider asking for help first before
>> sending them to the main list.
>
>Note, I do not want additional changes to this document, my Reviewed-by
>still stands with this version, it is good, ship it.
>
>However, I do want to endorse this sentiment as uniquely capturing a
>truism of kernel development that perhaps belongs in
>Documentation/process/submitting-patches.rst. It captures it in a way
>that avoids the conceit of the "slop is special" argument.
>
>Contributions are accepted in large part based in trust in the author.
>So much so that even long time contributors self censor, self mistrust,
>based on the adage "debugging is harder than developing, if you develop
>at the limits of your cleverness you will not be able to debug the
>result." Tools potentially allow you to develop beyond the limits of
>your own cleverness which implicates the result as "undebuggable" and
>unmaintainable.
>
>So a simple rule of "generally you should be able to demonstrate the
>ability to substantively review a contribution of similar complexity
>before expecting the kernel community to engage in earnest" mitigates
>the asymmetric threat of AI contributions *and* contributors that have
>not built-up enough trust capital with their upstream maintainer.

Looking at recent history (v6.12..v6.18) we had 1902 authors (a third of
overall contributors) who contributed a single commit. Out of those 1902, only
177 have a Reviewed-by tag pointing to them.

With a rule like the above, 1700+ contributors would have not been able to send
their patch in.

-- 
Thanks,
Sasha

On Tue, 13 Jan 2026 13:43:14 -0500
Sasha Levin <sashal@kernel.org> wrote:

> >Contributions are accepted in large part based in trust in the author.
> >So much so that even long time contributors self censor, self mistrust,
> >based on the adage "debugging is harder than developing, if you develop
> >at the limits of your cleverness you will not be able to debug the
> >result." Tools potentially allow you to develop beyond the limits of
> >your own cleverness which implicates the result as "undebuggable" and
> >unmaintainable.

Trust does play a large role here. I get annoyed when someone I never heard
of sends me a patch because a tool told them it was wrong but when looking
at the code, the tool was wrong.

Every so often Dan sends me one of these types of patches because of a
false positive in smatch or something like that. But Dan also sends me
overwhelming more patches that actual fix real bugs. The signal to noise
ratio is rather high with Dan so I never get annoyed from a missed patch
here or there.

But someone I never heard of sending me one of these are totally annoying
as the signal to noise ratio is 0 for them :-p

> >
> >So a simple rule of "generally you should be able to demonstrate the
> >ability to substantively review a contribution of similar complexity
> >before expecting the kernel community to engage in earnest" mitigates
> >the asymmetric threat of AI contributions *and* contributors that have
> >not built-up enough trust capital with their upstream maintainer.  
> 
> Looking at recent history (v6.12..v6.18) we had 1902 authors (a third of
> overall contributors) who contributed a single commit. Out of those 1902, only
> 177 have a Reviewed-by tag pointing to them.
> 
> With a rule like the above, 1700+ contributors would have not been able to send
> their patch in.

But were these all tool submissions?

I also wouldn't expect (or particularly want) new contributors doing
reviews. I think "Reported-by" is a much better metric for new submitters.
I trust people who found real bugs more than people that just slap their
"Reviewed-by" tag on something they probably don't understand.

-- Steve

On Tue, 2026-01-13 at 13:43 -0500, Sasha Levin wrote:
> On Tue, Jan 13, 2026 at 10:20:44AM -0800,
> dan.j.williams@intel.com wrote:
[...]
> > So a simple rule of "generally you should be able to demonstrate
> > the ability to substantively review a contribution of similar
> > complexity before expecting the kernel community to engage in
> > earnest" mitigates the asymmetric threat of AI contributions *and*
> > contributors that have not built-up enough trust capital with their
> > upstream maintainer.
> 
> Looking at recent history (v6.12..v6.18) we had 1902 authors (a third
> of overall contributors) who contributed a single commit. Out of
> those 1902, only 177 have a Reviewed-by tag pointing to them.
> 
> With a rule like the above, 1700+ contributors would have not been
> able to send their patch in.

It's not just that.  Even today Reviewed-by: doesn't always mean the
subject of the tag actually understood it.  We do see a lot of patches
(particularly drivers from companies) that come to the lists  with
fully formed reviewed-by tags and no backing record.  Trying to
institute a reviewed-by requirement would drastically exacerbate this
and, even worse, produce a large uptick in pseudo reviews from people
trying to get the tag to submit.

Speaking as a drive by committer with quite a body of work, the worst
projects to come to are those with artificial worthiness metrics (like
n reviews or stars or github badges or whatever).  Even if you can be
bothered to get over the hump, whatever you did is usually irrelevant
to the patch you want to submit.

The best indication that a committer understood what they were touching
should be in the change log.  If they understand the system under
patch, they should be able to explain clearly why the patch is needed
and what its effects are.

Regards,

James

Sasha Levin wrote:
[..]
> With a rule like the above, 1700+ contributors would have not been able to send
> their patch in.

Good point, I am not suggesting a Reviewed-by hurdle, but can see it
reading that way. I expect that there will always be a significant class
of contributions that will never need author trust to be accepted. Yes,
would need to be careful not to destroy that wellspring of new
contributors.

On Tue, Jan 13, 2026 at 10:51 AM <dan.j.williams@intel.com> wrote:
>
> Sasha Levin wrote:
> [..]
> > With a rule like the above, 1700+ contributors would have not been able to send
> > their patch in.
>
> Good point, I am not suggesting a Reviewed-by hurdle, but can see it
> reading that way. I expect that there will always be a significant class
> of contributions that will never need author trust to be accepted. Yes,
> would need to be careful not to destroy that wellspring of new
> contributors.

You brought up an excellent point and I think it should be documented
in submitting-patches.rst:
A developer "should be able to demonstrate the
ability to substantively review a contribution of similar complexity
before expecting the kernel community to engage in earnest".

In bpf and netdev communities we ask developers to participate
in code reviews and publish metrics:
https://lore.kernel.org/bpf/?q=s%3A%22bpf+development+stats%22

A bit gamified rankings, but the message is clear:
want to land patches faster? participate in code reviews!
It reduces maintainers load and demonstrates that code-reviewing
developers actually understand the code, builds maintainer's trust.

On 1/12/26 21:30, Dan Carpenter wrote:
>> +If tools permit you to generate a contribution automatically, expect
>> +additional scrutiny in proportion to how much of it was generated.
>> +
>> +As with the output of any tooling, the result may be incorrect or
>> +inappropriate. You are expected to understand and to be able to defend
>> +everything you submit. If you are unable to do so, then do not submit
>> +the resulting changes.
>> +
>> +If you do so anyway, maintainers are entitled to reject your series
>> +without detailed review.
> Argh... Flip.  In context, that sounds even more sinister and
> threatening than my over the top proposal.  We have to "defend"
> everything?  "If you do so anyway" sounds like we're jumping to a
> "per my last email" from the get go.  What about:
> 
> If tools permit you to generate a contribution automatically, expect
> additional scrutiny in proportion to how much of it was generated.
> 
> Every kernel patch needs careful review from multiple people.  Please,
> don't start the public review process until after you have carefully
> reviewed the patches yourself.  If you don't have the necessary
> expertise to review kernel code, consider asking for help first before
> sending them to the main list.
> 
> Ideally, patches would be tested but we understand that that's not
> always possible.  Be transparent about how confident we can be that the
> changes don't introduce new problems and how they have been tested.
> 
> Bug reports especially are very welcome.  Bug reports are more likely
> to be dealt with if they can be tied to the individual commit which
> introduced them.  With new kinds of warnings, it is better to send
> a few at a time at the start to see if they are a real issue or how
> they can be improved.

Hey Dan,

I agree with most of what you wrote here in general. My only issue with
it is that it seems to be good, generic advice and isn't specific to
tooling-generated contributions.

For instance, this suggests saying:

	"Ideally, patches would be tested..."

Testing is covered in Documentation/process/submit-checklist.rst and in
a few other places. The thing that I do think belongs in this document
(and is missing in v5) is a note that maintainers might expect *extra*
testing from tool-generated content. I've added a blurb like that to my
working v6 version.

Are there other things that are missing and truly specific to
tooling-generated contributions that aren't covered in other documentation?

On Tue, Jan 13, 2026 at 08:30:51AM +0300, Dan Carpenter wrote:
> On Mon, Jan 12, 2026 at 04:06:12PM -0800, Dave Hansen wrote:
> > +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.
> > + - Treat the contribution specially like reviewing with extra scrutiny,
> > +   or at a lower priority than human-generated content.
> > + - 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 be assured that the submitter fully
> > +   understands how the code works.
> > +
> > +If tools permit you to generate a contribution automatically, expect
> > +additional scrutiny in proportion to how much of it was generated.
> > +
> > +As with the output of any tooling, the result may be incorrect or
> > +inappropriate. You are expected to understand and to be able to defend
> > +everything you submit. If you are unable to do so, then do not submit
> > +the resulting changes.
> > +
> > +If you do so anyway, maintainers are entitled to reject your series
> > +without detailed review.
>
> Argh... Flip.  In context, that sounds even more sinister and
> threatening than my over the top proposal.  We have to "defend"
> everything?  "If you do so anyway" sounds like we're jumping to a
> "per my last email" from the get go.  What about:

I disagree entirely - you have to be able to understand what you submit and
defend it in code review this is absolutely standard stuff for _any_ kernel
submission whether tool-assisted or not.

I don't think there's anything sinister there at all, and I think it's a
really good way of _clearly_ communicating the fundamental requirements
here.

>
> If tools permit you to generate a contribution automatically, expect
> additional scrutiny in proportion to how much of it was generated.
>
> Every kernel patch needs careful review from multiple people.  Please,

OK so now you're contradicting the key point that we can reject slop out of
hand, which is deeply counterproductive.

A guy sends 500 tool-generated patches and now _according to the doc_ it
needs _careful_ review from _multiple_ people? No.

I also think this is stepping outside tooling documentation and essentially
asserting things about kernel review in general that is really out of scope
here.

> don't start the public review process until after you have carefully
> reviewed the patches yourself.  If you don't have the necessary

A useless person will 'review' it in advance without issue.

Requiring _understanding_ is a lot clearer I think.

> expertise to review kernel code, consider asking for help first before
> sending them to the main list.

Please no, maintainers have enough to do :)

If you don't understand and, if a maintainer asks questions, can't defend
what you've done, just don't send it at all. Simple, easy, clear.

>
> Ideally, patches would be tested but we understand that that's not
> always possible.  Be transparent about how confident we can be that the

This is again stating some kind of policy that's very off-topic here.

> changes don't introduce new problems and how they have been tested.

This is actually bad - you're saying it's ok to send whatever, as long as
you're transparent about how confident you are? Perhaps a clueless person
is very confident the tooling in question got it right?

Again I feel requiring understanding is a clearer criteria here.

>
> Bug reports especially are very welcome.  Bug reports are more likely
> to be dealt with if they can be tied to the individual commit which
> introduced them.  With new kinds of warnings, it is better to send
> a few at a time at the start to see if they are a real issue or how
> they can be improved.

Again this feels very much out of scope.

Overall your suggested change undermines the purpose of suggested addition
- to _emphasise_ that we don't want nonsense submissions and to state this
in _clear_ terms.

I get where you're coming from, but I don't think there is any sinister
undertone here - it's completely standard in kernel review for people to
challenge what you've done and for you to need to be able to defend it.

It doesn't imply aggression requiring defence or something like this, but
rather very clearly setting some extremely minimal, sensible, ground rules.

>
> regards,
> dan carpenter
>

Cheers, Lorenzo