lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2428ab19-c134-4ee1-b7ef-01710d1e528c@lucifer.local>
Date: Fri, 9 Jan 2026 15:35:12 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Dan Carpenter <dan.carpenter@...aro.org>, Dave Hansen <dave@...1.net>,
        Dave Hansen <dave.hansen@...el.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
        Kees Cook <kees@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Miguel Ojeda <ojeda@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>,
        SeongJae Park <sj@...nel.org>, Dan Williams <dan.j.williams@...el.com>,
        NeilBrown <neilb@...mail.net>, Theodore Ts'o <tytso@....edu>,
        Sasha Levin <sashal@...nel.org>, Jonathan Corbet <corbet@....net>,
        Vlastimil Babka <vbabka@...e.cz>, workflows@...r.kernel.org,
        ksummit@...ts.linux.dev
Subject: Re: [PATCH] [v3] Documentation: Provide guidelines for
 tool-generated content

On Fri, Jan 09, 2026 at 10:28:46AM -0500, Steven Rostedt wrote:
> On Fri, 9 Jan 2026 07:28:01 +0000
> Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
>
> > > It's better to have a grumpy document, instead of grumpy emails.  We
> > > need it to sound grumpy and it needs to be the first paragraph.
>
> I disagree. Specifically because of what Linus had said  (see below).
>
> > >
> > > AI Slop:  AI can generate a ton of patches automatically which creates a
> > > burden on the upstream maintainers.  The maintainers need to review
> > > every line of every patch and they expect the submitters to demonstrate
> > > that even the generated code was verified to be accurate.  If you are
> > > unsure of whether a patch is appropriate then do not send it.  NO AI
> > > SLOP!
> > >
> > > Of course, sensible people don't need to be told this stuff, but there
> > > are well intentioned people who need it explained.
> > >
> > > regards,
> > > dan carpenter
> > >
> >
> > Exactly.
> >
> > Every version of watering it down just makes it meaningless noise. The point is
> > to emphasise this.
>
> The thing is, the AI slop sending culprits are not going to be the ones to
> read this. It's the people who want to do the right thing that this
> document is focused on and that's why I think it should be more welcoming.

I think you and Linus are wrong about this. There are a class of 'good intent
bad results' people who will absolutely do this _and_ pay attention to the
document.

I expect you as a maintainer must have run into this, I know I have!

And given how inaccurate that register article was, I think you can see that
having something clear matters from that perspective too, in practice.

>
> That said, I just started looking at your other email and that does look
> better. I'll reply there.

Thanks!

>
> -- Steve

Cheers, Lorenzo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ