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

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 30 Jul 2025 12:36:25 -0400
Sasha Levin <sashal@kernel.org> wrote:

> >
> >That sounds pretty much exactly as what I was stating in our meeting. That
> >is, it is OK to submit a patch written with AI but you must disclose it. It
> >is also the right of the Maintainer to refuse to take any patch that was
> >written in AI. They may feel that they want someone who fully understands  
> 
> This should probably be a stronger statement if we don't have it in the
> docs yet: a maintainer can refuse to take any patch, period.

I disagree with that. They had better have technical reasons to refuse to
take a patch. I would have big qualms if a maintainer just said "I don't
like you and I'm not going to take any patches from you".

This is a community project, and maintainers have been overridden before.
Luckily, Linus has been pretty good at getting changes into the kernel when
there was no clear technical argument that they should not be accepted.

I believe the policy is that a maintainer may refuse any patch based on
technical reasons. Now, patches can and are delayed due to maintainers just
not having the time to review the patch. But that is eventually resolved if
enough resources come into play.

My point here is that AI can now add questions that maintainers can't
answer. Is it really legal? Can the maintainer trust it? Yes, these too can
fall under the "technical reasons" but having a clear policy that states
that a maintainer may not want to even bother with AI generated code can
perhaps give the maintainer something to point to if push comes to shove.

> 
> >what that patch does, and AI can cloud the knowledge of that patch from the
> >author.  
> 
> Maybe we should unify this with the academic research doc we already
> have?

I wouldn't think so. This is about submitting patches and a statement there
may be easier found by those about to submit an AI patch. Just because they
are using AI doesn't mean they'll think it's an academic research.

> 
> This way we can extend MAINTAINERS to indicate which subsystems are
> more open to research work (drivers/staging/ comes to mind) vs ones that
> aren't.

I wouldn't call it research work. Right now people who may be playing with
AI models may think it's "research", but that's not going to be the
majority of AI submissions.

> 
> Some sort of a "traffic light" system:
> 
>   1. Green: the subsystem is happy to receive patches from any source.
> 
>   2. Yellow: "If you're unfamiliar with the subsystem and using any
>   tooling to generate your patches, please have a reviewed-by from a
>   trusted developer before sending your patch".
> 
>   3. No tool-generated patches without prior maintainer approval.

Perhaps. Of course there's the Coccinelle scripts that fix a bunch of code
around the kernel that will like be ignored in this. But this may still be
a good start.

-- Steve