Re: [MAINTAINERS SUMMIT] Annotating patches containing AI-assisted code

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Aug 05, 2025 at 02:16:17PM -0400, Sasha Levin wrote:
> On Tue, Aug 05, 2025 at 09:00:10PM +0300, Laurent Pinchart wrote:
> > On Tue, Aug 05, 2025 at 01:50:57PM -0400, Sasha Levin wrote:
> >> On Tue, Aug 05, 2025 at 05:38:36PM +0200, Jiri Kosina wrote:
> >> > This proposal is pretty much followup/spinoff of the discussion currently
> >> > happening on LKML in one of the sub-threads of [1].
> >> >
> >> > This is not really about legal aspects of AI-generated code and patches, I
> >> > believe that'd be handled well handled well by LF, DCO, etc.
> >> >
> >> > My concern here is more "human to human", as in "if I need to talk to a
> >> > human that actually does understand the patch deeply enough, in context,
> >> > etc .. who is that?"
> >> >
> >> > I believe we need to at least settle on (and document) the way how to
> >> > express in patch (meta)data:
> >> >
> >> > - this patch has been assisted by LLM $X
> >> > - the human understanding the generated code is $Y
> >> >
> >> > We might just implicitly assume this to be the first person in the S-O-B
> >> > chain (which I personally don't think works for all scenarios, you can
> >> > have multiple people working on it, etc), but even in such case I believe
> >> > this needs to be clearly documented.
> >>
> >> The above isn't really an AI problem though.
> >>
> >> We already have folks sending "checkpatch fixes" which only make code
> >> less readable or "syzbot fixes" that shut up the warnings but are
> >> completely bogus otherwise.
> >>
> >> Sure, folks sending "AI fixes" could (will?) be a growing problem, but
> >> tackling just the AI side of it is addressing one of the symptoms, not
> >> the underlying issue.
> >
> > Perfect, let's document a policy and kill two birds with one stone then.
> 
> So I've gone through some of our docs, and we already have the following
> in submitting-patches.rst:
> 
> 	Your patch will almost certainly get comments from reviewers on
> 	ways in which the patch can be improved, in the form of a reply
> 	to your email. You must respond to those comments; ignoring
> 	reviewers is a good way to get ignored in return. You can simply
> 	reply to their emails to answer their comments. Review comments
> 	or questions that do not lead to a code change should almost
> 	certainly bring about a comment or changelog entry so that the
> 	next reviewer better understands what is going on.
> 
> 	Be sure to tell the reviewers what changes you are making and to
> 	thank them for their time.  Code review is a tiring and
> 	time-consuming process, and reviewers sometimes get grumpy.
> 	Even in that case, though, respond politely and address the
> 	problems they have pointed out.  When sending a next version,
> 	add a ``patch changelog`` to the cover letter or to individual
> 	patches explaining difference against previous submission (see
> 	:ref:`the_canonical_patch_format`).  Notify people that
> 	commented on your patch about new versions by adding them to the
> 	patches CC list.
> 
> In the context of this discussion it's a bit funny: we mandate that
> reviews will be responded to, but we don't mandate that the response
> will make any sense, which I think is Jiri's point.

I would consider that strongly implied. Are there contributors who could
in good faith consider that responses that don't make any sense are
perfectly fine ? If we had to state that explicitly, there would be
thousands of other assumptions we would need to document.

What I believe we need to document is the assumptions we make that may
not be self-evident to contributors. I assume that patches I receive are
understood by the author, as well as by the submitter unless stated
otherwise. LLMs may empower new (or existing) contributors to submit
more easily and in larger quantities patches that neither them nor
anyone else understand. If we all think nobody in their right mind would
do that, then there's nothing to document. I think the rule needs to be
stated clearly, as I'm concerned we'll see an increase in such
submissions.

> The TIP maintainer's handbook (maintainer-tip.rst) actually seems to
> tackle this:
> 
>     SOBs after the author SOB are from people handling and transporting
>     the patch, but were not involved in development. SOB chains should
>     reflect the **real** route a patch took as it was propagated to us,
>     with the first SOB entry signalling primary authorship of a single
>     author.
> 
> Should we clarify that this is true for any kernel patches?

This seems to be related to
https://lore.kernel.org/all/20250724072032.118554-1-hendrik.hamerlinck@hammernet.be/

-- 
Regards,

Laurent Pinchart