From: Sasha Levin <sashal@kernel.org>
To: dan.j.williams@intel.com
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
Kees Cook <kees@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Miguel Ojeda <ojeda@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
SeongJae Park <sj@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
"Paul E . McKenney" <paulmck@kernel.org>,
Simon Glass <simon.glass@canonical.com>,
NeilBrown <neilb@ownmail.net>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Theodore Ts'o <tytso@mit.edu>, Jonathan Corbet <corbet@lwn.net>,
Vlastimil Babka <vbabka@suse.cz>,
workflows@vger.kernel.org, ksummit@lists.linux.dev
Subject: Re: [PATCH] [v5] Documentation: Provide guidelines for tool-generated content
Date: Tue, 13 Jan 2026 13:43:14 -0500 [thread overview]
Message-ID: <aWaSQsl8h2wnBjzj@laps> (raw)
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
next prev parent reply other threads:[~2026-01-13 18:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 0:06 [PATCH] [v5] Documentation: Provide guidelines for tool-generated content Dave Hansen
2026-01-13 5:30 ` Dan Carpenter
2026-01-13 9:28 ` Lorenzo Stoakes
2026-01-13 18:20 ` Dave Hansen
2026-01-13 18:20 ` dan.j.williams
2026-01-13 18:43 ` Sasha Levin [this message]
2026-01-13 18:50 ` dan.j.williams
2026-01-13 21:03 ` Alexei Starovoitov
2026-01-13 19:33 ` James Bottomley
2026-01-13 22:44 ` Steven Rostedt
2026-01-13 9:09 ` Lorenzo Stoakes
2026-01-13 10:36 ` Lee Jones
2026-01-13 18:05 ` Dave Hansen
2026-01-13 18:55 ` Geert Uytterhoeven
2026-01-15 15:04 ` Lee Jones
2026-01-13 19:22 ` Jonathan Corbet
2026-01-19 19:57 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWaSQsl8h2wnBjzj@laps \
--to=sashal@kernel.org \
--cc=corbet@lwn.net \
--cc=dan.carpenter@linaro.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=kees@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mcgrof@kernel.org \
--cc=neilb@ownmail.net \
--cc=ojeda@kernel.org \
--cc=paulmck@kernel.org \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=simon.glass@canonical.com \
--cc=sj@kernel.org \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.