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

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: <CANiq72nmAw0sZZHJfSoHOZ5rXgoi7O4kETASp2F62XyALqZ8gA@mail.gmail.com>
Date: Thu, 8 Jan 2026 12:43:50 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: dan.j.williams@...el.com, Dave Hansen <dave@...1.net>, 
	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>, Steven Rostedt <rostedt@...dmis.org>, 
	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 Thu, Jan 8, 2026 at 11:29 AM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> I really don't think it is the case that maintainers can simplly dismiss an
> entire series like that.

I think Dan was referring to all kinds of series, i.e. maintainers
have leeway to reject proposals, whether they are big or small and
whether they are new features or cleanups.

After all, the project works by trusting maintainers to do the right
thing (i.e. the best they can with the information and time at their
disposal), but sometimes there may not be concrete technical reasons.

For instance, sometimes it is just a matter of bandwidth -- if
maintainers cannot maintain the code, and no one (that is trusted to
some degree) is willing to do so, then it would be a bad idea to take
the code anyway, even if the feature is great, whether LLM-generated
or not.

That is also why it is often said that it is a good idea to contact
maintainers/community before developing completely a new feature etc.
etc.

So if a subsystem suddenly starts to get an onslaught of series like
you warn about, then they cannot be expected to review and give
technical feedback to everything, and they will need to prioritize
somehow (e.g. fixes), or try to get more maintainers, or raise the
issue in ksummit, etc.

At least, that is my take, i.e. we need to allow maintainers to adjust
as things come. And, of course, as a community, we can always reassess
as conditions change.

Cheers,
Miguel