* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dan Carpenter @ 2026-01-12 19:02 UTC (permalink / raw)
To: James Bottomley
Cc: Matthew Wilcox, Serge E. Hallyn, Lorenzo Stoakes, Liam R. Howlett,
Jens Axboe, Dave Hansen, Dave Hansen, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Dan Williams, Steven Rostedt,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <39da84e891a8ccd4a17115ce6a399c2f6498e78f.camel@HansenPartnership.com>
On Sat, Jan 10, 2026 at 11:02:19AM -0500, James Bottomley wrote:
> On Sat, 2026-01-10 at 15:52 +0000, Matthew Wilcox wrote:
> > On Sat, Jan 10, 2026 at 09:25:36AM -0600, Serge E. Hallyn wrote:
> > > I just don't think the word "slop" should be used, because while it
> > > may be very clear to you, and may be clearly defined in some
> > > communities, me, I'm just guessing what you mean by it.
> >
> > https://www.merriam-webster.com/wordplay/word-of-the-year
>
> Just because it's the word of the year this year doesn't mean people
> will remember what it means even after a few years. "Rawdog" was the
> OED word of the year in 2024 ... that's losing its resonance and who of
> the under 30 crowd knows what the 2000 word of the year "chad" means?
> The point of the formulation I proposed (without mentioning slop) was
> to be generic and retain its meaning over time.
Slop means you produced the patches in such quantity that you don't have
time to review the output before sending it. This isn't a totally new
thing, people have used clang-format to reformat a whole driver and it's
clear they didn't look at the output.
Even for bug reports, the truth is that no one reads mass bug reports.
I occasionally send mass bug reports if I create a new warning. No one
ever reads them.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-13 0:06 UTC (permalink / raw)
To: linux-kernel
Cc: Dave Hansen, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
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
^ permalink raw reply related
* [PATCH RESEND v2] checkpatch: Suppress warnings when Reported-by: is followed by Link:
From: Cryolitia PukNgae via B4 Relay @ 2026-01-13 3:22 UTC (permalink / raw)
To: Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn
Cc: workflows, linux-kernel, linux-mm, linux-doc, ltp, niecheng1,
zhanjun, Cryolitia PukNgae
From: Cryolitia PukNgae <cryolitia@uniontech.com>
> The tag should be followed by a Closes: tag pointing to the report,
> unless the report is not available on the web. The Link: tag can be
> used instead of Closes: if the patch fixes a part of the issue(s)
> being reported.
Accroding to Documentation/process/submitting-patches.rst , Link: is
also acceptable to followed a Reported-by:
Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com>
---
Link to previous: https://lore.kernel.org/r/20251023-checkpatch-v1-1-ff73ed1027d6@uniontech.com
---
scripts/checkpatch.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c0250244cf7a..dac9d98133c6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3209,10 +3209,10 @@ sub process {
if ($sign_off =~ /^reported(?:|-and-tested)-by:$/i) {
if (!defined $lines[$linenr]) {
WARN("BAD_REPORTED_BY_LINK",
- "Reported-by: should be immediately followed by Closes: with a URL to the report\n" . $herecurr . "\n");
- } elsif ($rawlines[$linenr] !~ /^closes:\s*/i) {
+ "Reported-by: should be immediately followed by Closes: or Link: with a URL to the report\n" . $herecurr . "\n");
+ } elsif ($rawlines[$linenr] !~ /^(closes|link):\s*/i) {
WARN("BAD_REPORTED_BY_LINK",
- "Reported-by: should be immediately followed by Closes: with a URL to the report\n" . $herecurr . $rawlines[$linenr] . "\n");
+ "Reported-by: should be immediately followed by Closes: or Link: with a URL to the report\n" . $herecurr . $rawlines[$linenr] . "\n");
}
}
}
---
base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
change-id: 20250919-checkpatch-0276787ebfbe
Best regards,
--
Cryolitia PukNgae <cryolitia@uniontech.com>
^ permalink raw reply related
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Dan Carpenter @ 2026-01-13 5:30 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260113000612.1133427-1-dave.hansen@linux.intel.com>
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
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-13 9:09 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <20260113000612.1133427-1-dave.hansen@linux.intel.com>
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
>
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-13 9:28 UTC (permalink / raw)
To: Dan Carpenter
Cc: Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, Paul E . McKenney, Simon Glass,
NeilBrown, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWXYi35pu9IHf2eE@stanley.mountain>
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
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Lee Jones @ 2026-01-13 10:36 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260113000612.1133427-1-dave.hansen@linux.intel.com>
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 [李琼斯]
^ permalink raw reply
* Re: [PATCH v1 01/30] docs: reporting-issues: mention text is best viewed rendered
From: Thorsten Leemhuis @ 2026-01-13 14:18 UTC (permalink / raw)
To: Jonathan Corbet
Cc: workflows, linux-doc, regressions, linux-kernel, Randy Dunlap
In-Reply-To: <87v7k0ntzj.fsf@trenco.lwn.net>
On 10/27/25 18:18, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@leemhuis.info> writes:
>
>> Add a comment before the step-by-step guide explaining that the document
>> is best viewed in the rendered form, as there the internal links will
>> work that later patches will add.
>>
>> While at it change the double quotes in the license hint at the end of
>> the document into single quotes, which is the preferred style.
>
> That is the classic marker of an independent change, of course.
Yeah, I tried to not split things up too much. But that doesn't matter
now anyway:
> But
> more significantly ... "preferred" by who? Double quotes are the normal
> English style that folks like me learned many years ago...
I removed those changes after that comment and Randy's NAK; I think I
miss-interpreted or miss-remembered a comment in a review a while ago.
> Otherwise seems OK.
Thx!
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH v1 02/30] docs: reporting-issues: tweak the reference section intro
From: Thorsten Leemhuis @ 2026-01-13 14:30 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: workflows, linux-doc, regressions, linux-kernel
In-Reply-To: <87qzuontlj.fsf@trenco.lwn.net>
On 10/27/25 18:27, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@leemhuis.info> writes:
>
>> Small improvements to the intro of the reference section.
>
> That's a bit uninformative ... what is the purpose of these
> improvements? That information would be especially helpful in a patch
> that simply replaces that section altogether.
Sorry, yes, of course, changes that to
"""
Fine tuning to the intro of the reference section:
* Call the step-by-step guide what it is.
* Reorder the links to the guides on bug reporting to first mention the
most modern one.
* Many small changes to streamline the text and slightly shorten it
"""
>> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
>> ---
>> .../admin-guide/reporting-issues.rst | 67 +++++++++----------
>> 1 file changed, 31 insertions(+), 36 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
>> index 3bc47afaf85ea0..90b50c27c0d2b6 100644
>> --- a/Documentation/admin-guide/reporting-issues.rst
>> +++ b/Documentation/admin-guide/reporting-issues.rst
>> @@ -244,42 +244,37 @@ The reference section below explains each of these steps in more detail.
>
> [...]
>
>> +The step-by-step guide above outlines all the major steps in brief fashion,
>> +which usually covers everything required. But even experienced users will
>> +sometimes wonder how to actually realize some of those steps or why they are
>> +needed; there are also corner cases the guide ignores for readability. That is
>> +what the entries in this reference section are for, which provide additional
>> +information for each of the steps in the detailed guide.
>> +
>> +A few words of general advice:
>> +
>> +* The Linux kernel developers are well aware that reporting bugs to them is
>> + more complicated and demanding than in other FLOSS projects. Quite a few
>> + would love to make it simpler. But that would require convincing a lot of
>> + developers to change their habits; it, furthermore, would require improvements
>> + on several technical fronts and people that constantly take care of various
>> + things. Nobody has stepped up to do or fund that work.
>
> This paragraph ... essentially says "we're making it hard on you because
> kernel developers can't be bothered to work on GitHub".
/me looks puzzled
/me noticed that Jonathan is right
/me looks puzzled in a different way
> I'm not sure this paragraph is needed at all but, if
> you're going to keep it, have it at least reflect that the complexity of
> problem reporting has a lot to do with the complexity of the problem
> domain rather than developers who are stuck in their habits.
Considered dropping it, but in the end decided that I think it's wort it
and changed it to:
* The Linux developers are well aware that reporting bugs to them is
more complicated and demanding than in other FLOSS projects. Some of it
is because the kernel is different, among others due to its mail-driven
development process and because it consists mostly of drivers. Some of
it is because improving things would require work in several technical
areas and people triaging bugs –– and nobody has stepped up to do or
fund that work.
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH v1 03/30] docs: reporting-issues: add conclusion to the step-by-step guide
From: Thorsten Leemhuis @ 2026-01-13 14:33 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: workflows, linux-doc, regressions, linux-kernel
In-Reply-To: <87ms5cntho.fsf@trenco.lwn.net>
On 10/27/25 18:29, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@leemhuis.info> writes:
[...]
>> +If any of that applies, please take a moment and let the primary author of this
>> +text, Thorsten Leemhuis <linux@leemhuis.info>, know by email while ideally CCing
>> +the public Linux docs mailing list <linux-doc@vger.kernel.org>. Such feedback is
>> +vital to improve this text further, which is in everybody's interest, as it will
>> +enable more people to master the task described here.
>> +
>
> Consider also soliciting patches to improve it - one can always hope we
> can bring in some help...
Yeah, valid point, will use this:
If any of that applies, please let the developers know by
sending a short note or a patch to Thorsten Leemhuis
<linux@leemhuis.info> while ideally CCing the public Linux docs mailing
list <linux-doc@vger.kernel.org>.
And include a patch in the next submission that updates two other places
in the docs that use nearly the identical text.
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH v1 04/30] docs: reporting-issues: add proper appendix
From: Thorsten Leemhuis @ 2026-01-13 14:38 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: workflows, linux-doc, regressions, linux-kernel
In-Reply-To: <87ikg0nt2s.fsf@trenco.lwn.net>
On 10/27/25 18:38, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@leemhuis.info> writes:
>
>> Turn the "Why some bugs remain unfixed and some report are ignored"
>> section into a proper appendix while improving it slightly.
>>
>> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
>> ---
>> .../admin-guide/reporting-issues.rst | 102 +++++++++---------
>> 1 file changed, 54 insertions(+), 48 deletions(-)
>
> Some comments below,
Many thx, will all be addressed in the next version.
> but I have to ask: do we really need this section at all?
Will answer that in a reply to 5/30, which asked the same.
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH v1 05/30] docs: reporting-issues: outline why reporting is complicated
From: Thorsten Leemhuis @ 2026-01-13 16:07 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: workflows, linux-doc, regressions, linux-kernel
In-Reply-To: <87ecqonsse.fsf@trenco.lwn.net>
On 10/27/25 18:44, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@leemhuis.info> writes:
>
>> Replace the closing words with a section that describes why reporting
>> Linux kernel bugs is more complicated than in other FLOSS projects.
>>
>> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
>> ---
>> .../admin-guide/reporting-issues.rst | 67 ++++++++++++++++---
>> 1 file changed, 59 insertions(+), 8 deletions(-)
>
> So the text is OK but ... this is now the second section that is
> essentially a long apology for the kernel process being so difficult.
> It seems redundant with the other text, and I'm not convinced we need
> it.
>
> Again, length is an impediment to getting people to actually read this
> stuff; we should be trying to be as concise as we can. Do we really
> need this?
I thought about this for a while, but in the end I this section and the
one from 4/30 are worth it. Let me explain my line of thought:
* Yes, they make the document a longer, but it's in an appendix, which
makes it relatively obvious that these are optional background details
you don't have to read.
* You in your reply to 3/30 asked to "Consider also soliciting patches
to improve it" -- something I in the context had found obvious and not
worth mentioning, as I thought, "everybody that knows how to send
patches will do so without us mentioning it here". But for these two
sections it's different: is stuff that is obvious for us, but not
obvious for many non-developers (at least from what I see when
processing bugs/regressions reports= and relevant for them. That's
because the kernel IMHO is not "an open-source program like any other",
as you mentioned in a reply to 4/30:
- Other FLOSS software is relatively independent, but the kernel is
mostly drivers -- so without the right hardware, there sometimes is
nothing that developers can do in case of bugs. We also normally don't
remove orphaned code due to the "no regressions" rule, unless it's
getting really old and/or in the way, so there is nothing anybody will
do about a bug report -- which is unusual. The stuff in 4/30 explains
such aspects.
- The kernel development model is different in some important aspects,
which can be even confusing for people familiar with FLOSS practices.
Like the "mainline developers might not care about bugs in
stable/longterm kernels, while the stable team will leave things to the
mainline developers if the problem happens there, too". This is rare and
IMHO needs to be explained somewhere, as then we can point people to
this explanation that otherwise will just feel pushed around and become
annoyed by the kernel (some obviously will nevertheless feel that, but
that way we can get at least some people to understand things and/or on
our side).
Ciao, Thorsten
^ permalink raw reply
* [PATCH] docs: netdev: refine 15-patch limit
From: Simon Horman @ 2026-01-13 17:47 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet
Cc: netdev, workflows, linux-doc
The 15 patch limit is intended by the maintainers to cover
all outstanding patches on the mailing list, not just those
in a single patchset. Document this practice accordingly.
Signed-off-by: Simon Horman <horms@kernel.org>
---
Documentation/process/maintainer-netdev.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 989192421cc9db6c93c816f2dfb7afbe48dd25fc..d98d2f46129eb0eaf55e5106d50b214ddc7bfb67 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -363,6 +363,14 @@ just do it. As a result, a sequence of smaller series gets merged quicker and
with better review coverage. Re-posting large series also increases the mailing
list traffic.
+Limit patches outstanding on mailing list
+-----------------------------------------
+
+Avoid having more than 15 patches, across all series, outstanding for
+review on the mailing list. This limit is intended to focus developer
+effort on testing patches before upstream review. Aiding the quality of
+upstream submissions, and easing the load on reviewers.
+
.. _rcs:
Local variable ordering ("reverse xmas tree", "RCS")
^ permalink raw reply related
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-13 18:05 UTC (permalink / raw)
To: Lee Jones, Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260113103609.GA1902656@google.com>
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.
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-13 18:20 UTC (permalink / raw)
To: Dan Carpenter, Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWXYi35pu9IHf2eE@stanley.mountain>
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?
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: dan.j.williams @ 2026-01-13 18:20 UTC (permalink / raw)
To: Dan Carpenter, Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Sasha Levin, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWXYi35pu9IHf2eE@stanley.mountain>
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.
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Sasha Levin @ 2026-01-13 18:43 UTC (permalink / raw)
To: dan.j.williams
Cc: Dan Carpenter, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <69668cfc63bb1_875d1004@dwillia2-mobl4.notmuch>
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
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: dan.j.williams @ 2026-01-13 18:50 UTC (permalink / raw)
To: Sasha Levin, dan.j.williams
Cc: Dan Carpenter, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWaSQsl8h2wnBjzj@laps>
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.
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Geert Uytterhoeven @ 2026-01-13 18:55 UTC (permalink / raw)
To: Dave Hansen
Cc: Lee Jones, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, Paul E . McKenney, Simon Glass,
NeilBrown, Lorenzo Stoakes, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <921e154d-7e54-40ff-ae85-97b6cee7f8b2@intel.com>
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
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Jonathan Corbet @ 2026-01-13 19:22 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: Dave Hansen, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Sasha Levin, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <20260113000612.1133427-1-dave.hansen@linux.intel.com>
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
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: James Bottomley @ 2026-01-13 19:33 UTC (permalink / raw)
To: Sasha Levin, dan.j.williams
Cc: Dan Carpenter, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Steven Rostedt, Paul E . McKenney, Simon Glass, NeilBrown,
Lorenzo Stoakes, Theodore Ts'o, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWaSQsl8h2wnBjzj@laps>
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
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Alexei Starovoitov @ 2026-01-13 21:03 UTC (permalink / raw)
To: Dan Williams
Cc: Sasha Levin, Dan Carpenter, Dave Hansen, LKML, Shuah Khan,
Kees Cook, Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain,
SeongJae Park, Steven Rostedt, Paul E . McKenney, Simon Glass,
NeilBrown, Lorenzo Stoakes, Theodore Ts'o, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <69669404e2bf_875d10028@dwillia2-mobl4.notmuch>
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.
^ permalink raw reply
* Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-13 22:44 UTC (permalink / raw)
To: Sasha Levin
Cc: dan.j.williams, Dan Carpenter, Dave Hansen, linux-kernel,
Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Luis Chamberlain, SeongJae Park, Paul E . McKenney, Simon Glass,
NeilBrown, Lorenzo Stoakes, Theodore Ts'o, Jonathan Corbet,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <aWaSQsl8h2wnBjzj@laps>
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
^ permalink raw reply
* Re: [PATCH] docs: netdev: refine 15-patch limit
From: Jakub Kicinski @ 2026-01-14 1:34 UTC (permalink / raw)
To: Simon Horman
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Jonathan Corbet,
netdev, workflows, linux-doc
In-Reply-To: <20260113-15-minutes-of-fame-v1-1-0806b418c6fd@kernel.org>
On Tue, 13 Jan 2026 17:47:15 +0000 Simon Horman wrote:
> +Limit patches outstanding on mailing list
> +-----------------------------------------
> +
> +Avoid having more than 15 patches, across all series, outstanding for
> +review on the mailing list. This limit is intended to focus developer
> +effort on testing patches before upstream review. Aiding the quality of
> +upstream submissions, and easing the load on reviewers.
Thanks for adding this.
In practice I think the limit is also per tree (net vs net-next)
to avoid head of line blocking fixes.
^ permalink raw reply
* Re: [PATCH v1 05/30] docs: reporting-issues: outline why reporting is complicated
From: Thorsten Leemhuis @ 2026-01-14 5:02 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: workflows, linux-doc, regressions, linux-kernel
In-Reply-To: <ae9a3fec-4872-4cb7-9e9f-dbeafb4daab7@leemhuis.info>
On 1/13/26 17:07, Thorsten Leemhuis wrote:
> I thought about this for a while, but in the end I this section and the
> one from 4/30 are worth it.
And having slept about this once more, I after my reply yesterday now
think it might be wise to merge the important parts from 4/30 into this
patch -- that should get things shorter and still get across chat I care
about. Sorry, took me a moment to realize that.
Ciao, Thorsten
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox