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

[Sasha Levin <sashal@kernel.org>]

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.

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?

-- 
Thanks,
Sasha