[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250730133220.6e7e9370@gandalf.local.home>
Date: Wed, 30 Jul 2025 13:32:20 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
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, 30 Jul 2025 18:23:14 +0100
Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> > I don't think we should (or can) set a policy here for other
> > maintainers. Right now we allow tool-assisted contributions - flipping
> > this would mean we need to get an ack from at least a majority of the
> > MAINTAINERS folks.
>
> Sasha, with respect this is totally crazy.
I'll somewhat defend Sasha on this.
>
> 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 ;-)
>
> 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".
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.
>
> 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 ;-)
-- Steve
Powered by blists - more mailing lists