Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content

[Dan Carpenter <dan.carpenter@linaro.org>]

On Fri, Jan 09, 2026 at 07:48:35AM +0000, Lorenzo Stoakes wrote:
> +cc Jens as reference him
> 
> On Thu, Jan 08, 2026 at 03:14:37PM -0500, Steven Rostedt wrote:
> > On Thu, 8 Jan 2026 11:50:29 -0800
> > Dave Hansen <dave@sr71.net> wrote:
> >
> > > On 1/8/26 11:23, Lorenzo Stoakes wrote:
> > > > I'm also not sure why we're losing the scrutiny part?
> > > >
> > > > Something like:
> > > >
> > > > +If tools permit you to generate series entirely automatically, expect
> > > > +additional scrutiny.
> > >
> > > The reason I resisted integrating this is it tries to draw too specific
> > > a line in the sand. Someone could rightfully read that and say they
> > > don't expect additional scrutiny because the entire series was not
> > > automatically generated.
> 
> I mean you are making an absolutely valid point, I'd say that'd be a rather
> silly conclusion to take, but we have to be wary of 'lawyering' the doc
> here.
> 
> > >
> > > What I want to say is: the more automation your tool provides, the more
> > > scrutiny you get. Maybe:
> > >
> > > 	Expect increasing amounts of maintainer scrutiny on
> > > 	contributions that were increasingly generated by tooling.
> >
> > Honestly that just sounds "grumpy" to me ;-)
> >
> > How about something like:
> >
> > 	All tooling is prone to make mistakes that differ from mistakes
> > 	generated by humans. A maintainer may push back harder on
> > 	submissions that were entirely or partially generated by tooling
> > 	and expect the submitter to demonstrate that even the generated
> > 	code was verified to be accurate.
> >
> > -- Steve
> 
> I don't really read that as grumpy, I understand wanting to be agreeable
> but sometimes it's appropriate to be emphatic, which is the entire purpose
> of this amendment.
> 
> Taking into account Jens's input too:
> 
> +If tools permit you to generate series automatically, expect
> +additional scrutiny in proportion to how much of it was generated.
> +
> +As with the output of any tooling, the result maybe incorrect or
> +inappropriate, so you are expected to understand and to be able to defend
> +everything you submit. If you are unable to do so, then don't submit the
> +resulting changes.
> +
> +If you do so anyway, maintainers are entitled to reject your series without
> +detailed review.

This is too subtle.  In real life if we suspect a patchset is AI Slop,
then we're going to reject the whole thing immediately.  No one is
going to review all fifteen patches one by one as if we're searching
through monkey poo for edible grains of corn.

The AI slop patches I've seen were not bad actors.  Someone saw a
TODO in the file and thought that AI could solve it.  The patch
compiled, it was formatted correctly and the commit message sounded
confident so they sent it.

To me the audience for this is maybe a team working on AI and they
don't have any kernel developers on staff so they assume they're being
helpful sending unreviewed patches.  The message should be that every
patch needs to be reviewed carefully before it is sent upstream.  I've
been asked to review patches like this in the past.  Get outside help
if you need to, but every patch needs to be reviewed.

regards,
dan carpenter