Re: [PATCH] docs: remove Assisted-by references

[Kees Cook <kees@kernel.org>]

Oops, this reply ended up long, sorry! :P tl;dr: if you get bored,
please skip to my last paragraph.

On Tue, Oct 13, 2026 at 10:16:28PM +0200, Laurent Pinchart wrote:
> Perhaps, but I think that's missing the point. The SoB line is not
> enforceable either. Very few of our requirements and assumptions can be
> enforced. We're not telling people they can get backdoors merged in the
> kernel because we can't guarantee 100% that one won't sneak in.

I think the SoB is at least _more_ enforceable, in the sense that it
has mechanical validation attached to it ("sender matches SoB"), and
it's designed to be used to declare "chain of custody" in some way.
Specifically the SoB is about making a declaration of origin, DCO,
literally. :) So that tag does do what it says it does, and can be
meaningfully interrogated later.

But I agree, it's a statement that says "I brought this to the project",
and is _just_ a statement. What we want for the LLM stuff is "I
understand this change and am ready to convince other people about why
they, too, want it to be included in the project". "Assisted-by" never
did that. And I've always held that the place to do that is, and has
always been, in the commit message body itself.

> What this is about is setting our expectations, telling what we want and
> what we don't want. There's still value in that, and I'd argue there's
> even more value now. There will be people who won't care, there will be
> people who cheat. We've always had those, we'll keep having them, and
> we'll keep rejecting their contributions. I really don't get the
> unenforceable argument here.

I am perhaps using the wrong word, and maybe "enforceable" doesn't map
well. I think I mean "Assisted-by" is (and has always been[1]) irrelevant:
the thing we want to have is understanding, correctness, etc. This gets
called "patch quality" under the huge umbrella of what "quality" means.

And the LLMs change the nature of all of this, I agree, but the tag
didn't help at all. For example, I was (I think) responsible for
netdev's rule about "please don't send more than a dozen patches at
once; wait for us to process those before sending the next wave", due to
the treewide changes I've done over the years (where netdev also wanted
them broken up by driver, etc). And that was strictly a mechanical and
"trivial" set of changes (driven usually by Coccinelle). There was no
tag for that, and "enforcing" it was a social one. I did what they
asked, etc.

Recently we've seen an attempt to make that an enforceable delay by having
Sashiko hold off on patch reviews for 24 hours for netdev patches, etc.
In that case, there is a mechanical way to induce the result we want.
But "add a tag" wasn't it: that wasn't an "enforceable" solution to the
problem of quality and quantity.

> What would be your issue with writing commit messages manually ?

Up until about 4 months ago, I did 100% do that because the prose and
rationale coming out of the LLMs, even when guided toward specific
templates, was horrendously bad. But now it is, I think, substantially
better. I almost never take the result as-is still, but it produces a
commit message very close to what I want to see. And note that it's not
blindly producing it; I have extensive instructions about what I expect
and how it should go about it.

The resulting commit messages are better than what I would have written
alone. I spell poorly, I make typos, I forget to mention aspects that
were involved in coming to whatever design got implemented, I'm slow at
digging out the exact error or warning that was emitted into a build log,
I miss CCing someone who touched this area of code in a meaningful way
outside of get_maintainer's git history window, the list goes on and
on. The LLM reads faster, writes faster, and notices missed/forgotten
things better. So for me, I would be delinquent in NOT using its help
to write commit messages.

> Again, we're not aiming for 100% accuracy, we've never considered that
> goal reachable, LLMs or not.

I'm a maintainer for a bunch of subsystems, but I don't have remotely
anywhere near the level of patches coming in as other subsystems, so I'm
still in a little corner of gleeful obliviousness from the perspective of
dealing with review volume, but even I see drive-by patch dumps. I'm not
sure if/how this is scalable, or even the right answer, but the signals
I have for patch review tend to be:

- sender and area trust/reputation (If I'm getting a patch from someone
  that I've taken patches from before, I know I have in the past assessed
  their work as useful/helpful/robust/whatever. And I know what they
  have touched before: if I've landed a bunch of binfmt_elf patches from
  someone, and then later they send me pstore patches, I'm going to be
  surprised and then need to examine this new area of work from them.)

- testing (how was the change tested, how will it continue to be tested,
  etc. Compile-time? Run-time? Unit? Integration?)

- correctness, utility, maintainability, all the rest (the "core" review
  work)

Things like Sashiko give us some mechanistic view into "correctness"
(and I've been working on adding an analysis stage to Sashiko to cover
"testing"[2]). The first one (the matrix of trust across sender vs code
area) look significantly more filterable, though. (The parallel threads
on "ignore all new submitters" is an extreme, and IMO bad, form of
that filter.) Maintainers had been doing this filtering in their heads
basically, and the LLMs changed the volume of people sending patches,
and similarly disrupted the trust part too where suddenly people who
used to send good patches might be sending bad patches. The intent, as
I saw it, of "Assisted-by" was to give a signal about this latter form
(known person sending possibly bad patches suddenly), but it didn't really
work, and then both the LLMs got better and people using them figured out
(I hope) how to wield them better.

So, I'm kind of back to looking at some way to scale my understanding
of any given contributor's reputation[3], area of work, ownership
and responsibility of fixing mistakes, depth of understanding
of various topics outside of their common area of kernel work
(compilers? user-space?), rationality, friendliness, communication style,
etc. And my evaluative criteria is going to be different from other
maintainer's too, so outside of basic facts ("contributor has sent X
many patches"), this is highly subjective stuff that I suspect will
resist objective mechanistic handling.

-Kees

[1] https://lore.kernel.org/all/202507241337.F9595E1D@keescook/
[2] https://github.com/masoncl/review-prompts/pull/100
[3] https://lore.kernel.org/all/35426E86-9663-48D7-8899-B82D62D04A84@kernel.org/

-- 
Kees Cook