linux-kernel - Re: [PATCH 0/4] Add agent coding assistant configuration to Linux kernel

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: <eafe2f1f-c8f4-41d4-b590-94509093eca3@lucifer.local>
Date: Wed, 30 Jul 2025 19:04:13 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Sasha Levin <sashal@...nel.org>, Greg KH <greg@...ah.com>, corbet@....net,
        linux-doc@...r.kernel.org, workflows@...r.kernel.org,
        josh@...htriplett.org, kees@...nel.org, konstantin@...uxfoundation.org,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Dr. David Alan Gilbert" <linux@...blig.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Wed, Jul 30, 2025 at 01:32:20PM -0400, Steven Rostedt wrote:
>
> >
> > Assuming every maintainer accepts AI patches unless explicitly opted out is
> > very clearly not something that will be acceptable to people.
>
> You can opt out when you receive your first AI patch ;-)

Yeah, there's just no way maintainers are going to be fine with this.

But this is why mediating this via the maintainers summit is a great idea -
let's get that feedback there.

And if I'm wrong and everybody's cool with it I will happily eat copious
humble pie :)

>
> >
> > Assuming an LF policy most maintainers won't be aware of applies with the
> > kind of ramifications this will inevitably have seems very unreasonable to
> > me.
>
> This is why the policy should just be "It's up to the maintainer to decide
> if they will take the patch or not".

Isn't this just what review is? :)

I mean having a tag makes life easier on this front, but I think we should
be as conservative as possible, and in my view that position is to default
to not accepting.


>
> If the maintainer starts getting too many submissions, then they can update
> the MAINTAINERS file to say "stop all AI patches to me!". Just like we have
> an opt-in for to not be part of the get_maintainer.pl "touched this file"
> with the .get_maintainer.ignore script.

Again I really don't think this aligns with what maintainers will want.

But again I think that is better settled or at least addressed at the
maintainers summit.

>
>
> >
> > You might suggest presuming a policy for maintainers is inappropriate, but
> > you are doing so wrt the LF policy on the assumption everybody is aware and
> > agrees with it.
> >
> > That same document says individual projects can _override_ this as they
> > please. So the introduction of this document can very well override that.
> >
> > We at the very least need this to be raised at the maintainers summit with
> > a very clear decision on opt-in vs. opt-out, with the decision being
> > communicated clearly.
>
> Agreed.
>
> >
> > It's maintainers like me that'll have to deal with the consequences of
> > this.
>
> And you may be the first to opt-in ;-)

Well I'm taking no position on the issue at hand, more so how we do the
_policy_ bits, so who knows ;)

Cheers, Lorenzo