[MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Jonathan Corbet]

The use of LLMs in the development process appears to be a clear theme for
the upcoming summit.  On top of what others have already suggested, I think
we may want to consider these questions:

- Do we want to continue naming specific LLMs in the Assisted-by tags, or
  put something more generic?  I *think* that this thread:

    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/

  reached a consensus that "Assisted-by: LLM" was better than what we
  require now, but it might be good to ratify that in this setting.

- There is a lot of LLM-generated code that lacks an Assisted-by
  disclosure.  Often, that seems to be the result of ignorance of the
  rules; those contributors will start adding the tags when informed of the
  requirement.  But others just lie about it.  A rule that is widely
  ignored does not help anybody.  Can we come up with a way to get better
  compliance, or should we just drop the tag entirely?

- There are many first-time contributors coming in with LLM-generated
  patches.  At times, I could swear that every one of them is focused on
  documentation typos, but the truth of the matter is that they are
  reaching into subsystems all over the kernel.  We have some brand-new
  contributors making significant changes to dozens of subsystems.  An
  experienced developer would be hard-put to truly understand what those
  changes are doing; a newcomer is unlikely to have that understanding,
  and is unlikely to be around to fix eventual problems.

  Our maintainers are not scaling to handle this new flood, and I fear we
  are going to see some unfortunate things merged.  One LLM-driven newcomer
  recently nearly succeeded in establishing himself as the maintainer of
  lib/.  How do we hold the line against this stuff while remaining open to
  new developers?

- Our process is becoming increasingly dependent on proprietary tools.  We
  have done that before and, in 2005, it went pretty badly for us - and
  could have been worse.  How do we prepare for the inevitable rugpull?  I
  raised this last year, and it was largely brushed off, but I still think
  it's something we should be concerned about.

That's probably enough :)

jon

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Sasha Levin]

On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>The use of LLMs in the development process appears to be a clear theme for
>the upcoming summit.  On top of what others have already suggested, I think
>we may want to consider these questions:
>
>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
>  put something more generic?  I *think* that this thread:
>
>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
>
>  reached a consensus that "Assisted-by: LLM" was better than what we
>  require now, but it might be good to ratify that in this setting.

So originally I've added the full name of the tool and LLM because there was
interest in a later audit of the tools to determine how useful (or useless)
some of the tools are.

If those folks aren't interested in doing so anymore, then sure - we can drop
it.

But... I find it difficult to see the point of having the tag if we do that.

>- There is a lot of LLM-generated code that lacks an Assisted-by
>  disclosure.  Often, that seems to be the result of ignorance of the
>  rules; those contributors will start adding the tags when informed of the
>  requirement.  But others just lie about it.  A rule that is widely
>  ignored does not help anybody.  Can we come up with a way to get better
>  compliance, or should we just drop the tag entirely?

Similarily, I think that one of the bigger reasons for the tag was fear of the
unknown. We figured that we can tag those commits, and if we ever needed to do
something about it (revert commits because of copyright issues, broken tools,
UMN v2, etc) it would make our job easier.

I think that there's room to improve the machinery here (AGENTS.md in the root,
for example).

>- There are many first-time contributors coming in with LLM-generated
>  patches.  At times, I could swear that every one of them is focused on
>  documentation typos, but the truth of the matter is that they are
>  reaching into subsystems all over the kernel.  We have some brand-new
>  contributors making significant changes to dozens of subsystems.  An
>  experienced developer would be hard-put to truly understand what those
>  changes are doing; a newcomer is unlikely to have that understanding,
>  and is unlikely to be around to fix eventual problems.
>
>  Our maintainers are not scaling to handle this new flood, and I fear we
>  are going to see some unfortunate things merged.  One LLM-driven newcomer
>  recently nearly succeeded in establishing himself as the maintainer of
>  lib/.  How do we hold the line against this stuff while remaining open to
>  new developers?

Shouldn't it be a merits question rather than a tools question?

If the commits are correct, does it matter if they were written with an LLM? we
can insist more on supplying tests and demonstrating correctness, something we
seem to be doing quite rarely right now.

>- Our process is becoming increasingly dependent on proprietary tools.  We
>  have done that before and, in 2005, it went pretty badly for us - and
>  could have been worse.  How do we prepare for the inevitable rugpull?  I
>  raised this last year, and it was largely brushed off, but I still think
>  it's something we should be concerned about.

Are we dependent on them, or do we just find them very useful? If
Claude/Codex/etc goes away next month, will it stall any of our processes?

We have AI reviews, we have many AI tools that help both authors and
maintainers, but I don't think that any of them play an integral part of our
process.

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:

> > - There are many first-time contributors coming in with LLM-generated
> >  patches.  At times, I could swear that every one of them is focused on

> >  Our maintainers are not scaling to handle this new flood, and I fear we
> >  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >  recently nearly succeeded in establishing himself as the maintainer of
> >  lib/.  How do we hold the line against this stuff while remaining open to
> >  new developers?

> Shouldn't it be a merits question rather than a tools question?

> If the commits are correct, does it matter if they were written with an LLM? we
> can insist more on supplying tests and demonstrating correctness, something we
> seem to be doing quite rarely right now.

The issue (which a number of projects are facing) is as much one of
volume as anything else, the code generation machines are enabling the
generation and submision of volumes of code where things were previously 
constrained by human factors.  It can turn into a bit of a DoS.  I don't
have any particularly bright ideas here but it's definitely a thing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Sasha Levin]

On Thu, Jul 16, 2026 at 05:08:40PM +0100, Mark Brown wrote:
>On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
>> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>
>> > - There are many first-time contributors coming in with LLM-generated
>> >  patches.  At times, I could swear that every one of them is focused on
>
>> >  Our maintainers are not scaling to handle this new flood, and I fear we
>> >  are going to see some unfortunate things merged.  One LLM-driven newcomer
>> >  recently nearly succeeded in establishing himself as the maintainer of
>> >  lib/.  How do we hold the line against this stuff while remaining open to
>> >  new developers?
>
>> Shouldn't it be a merits question rather than a tools question?
>
>> If the commits are correct, does it matter if they were written with an LLM? we
>> can insist more on supplying tests and demonstrating correctness, something we
>> seem to be doing quite rarely right now.
>
>The issue (which a number of projects are facing) is as much one of
>volume as anything else, the code generation machines are enabling the
>generation and submision of volumes of code where things were previously
>constrained by human factors.  It can turn into a bit of a DoS.  I don't
>have any particularly bright ideas here but it's definitely a thing.

Sure, we're seeing quite the increase in patch submissions, but I'm trying to
argue that the issue isn't a new one: lack of maintainers, trusted reviewers,
and maintainer burnout has been a topic at each kernel summit for as long as I
can remember. AI just kicks it up a notch.

My concern is that if we focus on the AI aspect, we still won't be solving the
underlying issue.

I'm hoping we can figure out how to get maintainers great tooling, testing, and
community, rather than figuring out how to block a developer who uses LLM.
Maybe AI would actually be a great catalyst for that as well?

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Jonathan Corbet]

Sasha Levin <sashal@kernel.org> writes:

> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>>The use of LLMs in the development process appears to be a clear theme for
>>the upcoming summit.  On top of what others have already suggested, I think
>>we may want to consider these questions:
>>
>>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
>>  put something more generic?  I *think* that this thread:
>>
>>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
>>
>>  reached a consensus that "Assisted-by: LLM" was better than what we
>>  require now, but it might be good to ratify that in this setting.
>
> So originally I've added the full name of the tool and LLM because there was
> interest in a later audit of the tools to determine how useful (or useless)
> some of the tools are.
>
> If those folks aren't interested in doing so anymore, then sure - we can drop
> it.
>
> But... I find it difficult to see the point of having the tag if we do that.

Folks like Greg have, in the recent past, said that it is useful even
without specific product-name information:

  https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/

>>- There are many first-time contributors coming in with LLM-generated
>>  patches.  At times, I could swear that every one of them is focused on
>>  documentation typos, but the truth of the matter is that they are
>>  reaching into subsystems all over the kernel.  We have some brand-new
>>  contributors making significant changes to dozens of subsystems.  An
>>  experienced developer would be hard-put to truly understand what those
>>  changes are doing; a newcomer is unlikely to have that understanding,
>>  and is unlikely to be around to fix eventual problems.
>>
>>  Our maintainers are not scaling to handle this new flood, and I fear we
>>  are going to see some unfortunate things merged.  One LLM-driven newcomer
>>  recently nearly succeeded in establishing himself as the maintainer of
>>  lib/.  How do we hold the line against this stuff while remaining open to
>>  new developers?
>
> Shouldn't it be a merits question rather than a tools question?
>
> If the commits are correct, does it matter if they were written with
> an LLM? we can insist more on supplying tests and demonstrating
> correctness, something we seem to be doing quite rarely right now.

It's definitely a merit question.  But we're not always all that good at
determining whether a commit is correct, and we depend a lot on the
contributor understanding their work and being around if something goes
wrong with it.  That is part of "merit" too.  How confident are we of
that merit when a brand-new developer makes significant changes to a
dozen or more unrelated subsystems?

>>- Our process is becoming increasingly dependent on proprietary tools.  We
>>  have done that before and, in 2005, it went pretty badly for us - and
>>  could have been worse.  How do we prepare for the inevitable rugpull?  I
>>  raised this last year, and it was largely brushed off, but I still think
>>  it's something we should be concerned about.
>
> Are we dependent on them, or do we just find them very useful? If
> Claude/Codex/etc goes away next month, will it stall any of our processes?
>
> We have AI reviews, we have many AI tools that help both authors and
> maintainers, but I don't think that any of them play an integral part of our
> process.

The related discussions have featured a number of maintainers talking
about how much time Sashiko has saved them.  I believe them.  How long
will it take until nobody does that level of patch review anymore?  What
will we do when the current round of corporate generosity ends and that
tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
like a possibility we should keep in mind.

jon

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Mauro Carvalho Chehab]

On Thu, 16 Jul 2026 12:36:53 -0600
Jonathan Corbet <corbet@lwn.net> wrote:

> Sasha Levin <sashal@kernel.org> writes:
> 
> > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:  
> >>The use of LLMs in the development process appears to be a clear theme for
> >>the upcoming summit.  On top of what others have already suggested, I think
> >>we may want to consider these questions:
> >>
> >>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
> >>  put something more generic?  I *think* that this thread:
> >>
> >>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> >>
> >>  reached a consensus that "Assisted-by: LLM" was better than what we
> >>  require now, but it might be good to ratify that in this setting.  
> >
> > So originally I've added the full name of the tool and LLM because there was
> > interest in a later audit of the tools to determine how useful (or useless)
> > some of the tools are.
> >
> > If those folks aren't interested in doing so anymore, then sure - we can drop
> > it.
> >
> > But... I find it difficult to see the point of having the tag if we do that.  
> 
> Folks like Greg have, in the recent past, said that it is useful even
> without specific product-name information:
> 
>   https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/

I never saw any merit on having such tag: it doesn't help reviewers
and doesn't provide any useful information at the git history. The
only think they eventually allow is for someone to reject a patch
without actually looking on it.

What we need to ensure is that:
1. the patch is good;
2. author carefully reviewed/modified it and not just did vibe-coding;
3. the author understands the proposed code.

Unfortunately, (2) and (3)s easily said than done as technology avances,
though.

Yet, I recently saw a patch series that sounded to be produced by vibe
coding, probably generated by some proprietary paid model. That was something 
that would very hardly be accepted by anyone, as LLM did lots of stupid
changes that are easily recognized as bad merge material. The final result was
also bad enough. So, for now, it is still easy to identify pure LLM generated
content.

> >>- There are many first-time contributors coming in with LLM-generated
> >>  patches.  At times, I could swear that every one of them is focused on
> >>  documentation typos, but the truth of the matter is that they are
> >>  reaching into subsystems all over the kernel.  We have some brand-new
> >>  contributors making significant changes to dozens of subsystems.  An
> >>  experienced developer would be hard-put to truly understand what those
> >>  changes are doing; a newcomer is unlikely to have that understanding,
> >>  and is unlikely to be around to fix eventual problems.
> >>
> >>  Our maintainers are not scaling to handle this new flood, and I fear we
> >>  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >>  recently nearly succeeded in establishing himself as the maintainer of
> >>  lib/.  How do we hold the line against this stuff while remaining open to
> >>  new developers?  
> >
> > Shouldn't it be a merits question rather than a tools question?
> >
> > If the commits are correct, does it matter if they were written with
> > an LLM? 

It does if the author doesn't understand the code and can't maintain
it without LLM. The bigger issue here is actually to allow people that
doesn't know how to code himself to become a maintainer. 

> > we can insist more on supplying tests and demonstrating
> > correctness, something we seem to be doing quite rarely right now.  

Perhaps we may need to have some interaction with the developers before
letting them to become new maintainers. This may allow checking if the
guy knows what he's doing or if he is only the man-in-the-middle.

> It's definitely a merit question.  But we're not always all that good at
> determining whether a commit is correct, and we depend a lot on the
> contributor understanding their work and being around if something goes
> wrong with it.  That is part of "merit" too.  How confident are we of
> that merit when a brand-new developer makes significant changes to a
> dozen or more unrelated subsystems?

If a brand-new developer is touching lots of unrelated subsystems,
there is a high chance that it is vibe-coding.

> 
> >>- Our process is becoming increasingly dependent on proprietary tools.  We
> >>  have done that before and, in 2005, it went pretty badly for us - and
> >>  could have been worse.  How do we prepare for the inevitable rugpull?  I
> >>  raised this last year, and it was largely brushed off, but I still think
> >>  it's something we should be concerned about.  
> >
> > Are we dependent on them, or do we just find them very useful? If
> > Claude/Codex/etc goes away next month, will it stall any of our processes?
> >
> > We have AI reviews, we have many AI tools that help both authors and
> > maintainers, but I don't think that any of them play an integral part of our
> > process.  
> 
> The related discussions have featured a number of maintainers talking
> about how much time Sashiko has saved them.  I believe them.  How long
> will it take until nobody does that level of patch review anymore?  What
> will we do when the current round of corporate generosity ends and that
> tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> like a possibility we should keep in mind.

This is a serious concern. It sounds risky to rely on that, as there's
no free lunch. We need to rely on something that can be managed in
an affordable way, prioritizing models that can run on affortable GPUs
and are open source.

Thanks,
Mauro

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Bart Van Assche]

On 7/16/26 11:36 AM, Jonathan Corbet wrote:
> What will we do when the current round of corporate generosity ends
> and that tool goes away?  Maybe I'm worrying too much, but this does 
> seem, to me, like a possibility we should keep in mind.

My understanding is that Sashiko is open source and also that it
supports multiple LLMs. I do not know whether it supports open weight
LLMs. Roman, please correct me if I got anything wrong.

Bart.

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Liam R. Howlett]

On 26/07/16 12:36PM, Jonathan Corbet wrote:
> Sasha Levin <sashal@kernel.org> writes:
> 
> > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> >>The use of LLMs in the development process appears to be a clear theme for
> >>the upcoming summit.  On top of what others have already suggested, I think
> >>we may want to consider these questions:
> >>
> >>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
> >>  put something more generic?  I *think* that this thread:
> >>
> >>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> >>
> >>  reached a consensus that "Assisted-by: LLM" was better than what we
> >>  require now, but it might be good to ratify that in this setting.
> >
> > So originally I've added the full name of the tool and LLM because there was
> > interest in a later audit of the tools to determine how useful (or useless)
> > some of the tools are.
> >
> > If those folks aren't interested in doing so anymore, then sure - we can drop
> > it.
> >
> > But... I find it difficult to see the point of having the tag if we do that.
> 
> Folks like Greg have, in the recent past, said that it is useful even
> without specific product-name information:
> 
>   https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/
> 

There are a few classes of LLM users, but as more and more people are
using LLM, the usefulness of this tag is converging on zero.  We seem to
have three classes of LLM users.

We have people leaning hard on LLMs to push more code, but are known
developers.  The uses of an LLM can be replaced by using an RFC tag for
things that _really_ should be looked at by others prior to acceptance.
That is, if they aren't using RFC already.

We have people using LLMs for writing tests or reviewing code.  A tag
here is not useful as it seems a false sense of security for reviewers
and they may skip it. The LLMs are finding off-by-ones, but the larger
ideas are usually sound and the test cases are actually not all bad.

> >>- There are many first-time contributors coming in with LLM-generated
> >>  patches.  At times, I could swear that every one of them is focused on
> >>  documentation typos, but the truth of the matter is that they are
> >>  reaching into subsystems all over the kernel.  We have some brand-new
> >>  contributors making significant changes to dozens of subsystems.  An
> >>  experienced developer would be hard-put to truly understand what those
> >>  changes are doing; a newcomer is unlikely to have that understanding,
> >>  and is unlikely to be around to fix eventual problems.
> >>
> >>  Our maintainers are not scaling to handle this new flood, and I fear we
> >>  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >>  recently nearly succeeded in establishing himself as the maintainer of
> >>  lib/.  How do we hold the line against this stuff while remaining open to
> >>  new developers?
> >
> > Shouldn't it be a merits question rather than a tools question?
> >
> > If the commits are correct, does it matter if they were written with
> > an LLM? we can insist more on supplying tests and demonstrating
> > correctness, something we seem to be doing quite rarely right now.

People who don't know what they are doing, cannot write tests that cover
the code they are changing.  They don't know what to ask the LLM to do.

Fundamentally, we've given some people a tool that stretches well
outside what they know, so requesting more testing will not result in
valid tests.  You end up writing things like "can you please ask your
LLM to <task>", or more likely something they can copy/paste into it
because they're saying they did it alone.

Half the time you tell them why it won't/doesn't work and they come back
with arguments from an LLM as to why you are wrong.

Also, they'll respin the reviewed patches within minutes, and that can
cost you hours to validate if it/they are not acceptable patch(es).

I've honestly thought about a rule where someone can no longer have
patches accepted again until the next release as they have exceeded a
threshold of time wastage.  (A nack merit?)

> 
> It's definitely a merit question.  But we're not always all that good at
> determining whether a commit is correct, and we depend a lot on the
> contributor understanding their work and being around if something goes
> wrong with it.  That is part of "merit" too.  How confident are we of
> that merit when a brand-new developer makes significant changes to a
> dozen or more unrelated subsystems?

The last class of users..

We have people writing patch sets across many subsystems and/or first
time people rewriting entire sections of the kernel to 'fix' things.

Some of these people are clearly passing off LLM work as their own,
without any LLM tag.  I am at a loss on how to deal with these.  Either
they are encouraged to try over and over, or they blow up at the
suggesting this is LLM and/or a NACK.  Neither method is good and nether
reduces the flow of bad code.

In any case, the tag is useless in this case because it's not going to
be used regardless of what we do.

So on Greg's note that having an LLM tag is a signal,  I question the
SNR now and if the signal is the same indicator across all patches.

> 
> >>- Our process is becoming increasingly dependent on proprietary tools.  We
> >>  have done that before and, in 2005, it went pretty badly for us - and
> >>  could have been worse.  How do we prepare for the inevitable rugpull?  I
> >>  raised this last year, and it was largely brushed off, but I still think
> >>  it's something we should be concerned about.
> >
> > Are we dependent on them, or do we just find them very useful? If
> > Claude/Codex/etc goes away next month, will it stall any of our processes?
> >
> > We have AI reviews, we have many AI tools that help both authors and
> > maintainers, but I don't think that any of them play an integral part of our
> > process.
> 
> The related discussions have featured a number of maintainers talking
> about how much time Sashiko has saved them.  I believe them.  How long
> will it take until nobody does that level of patch review anymore?  What
> will we do when the current round of corporate generosity ends and that
> tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> like a possibility we should keep in mind.
> 

Agreed.  I think we are already dependent enough on them to have a
visible impact on throughput.  That's going to increase as models become
better.  When the products shift from market capture to monetization,
we're going to have a dip in productivity and quality, at best.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Laurent Pinchart]

Hi Sasha,

On Thu, Jul 16, 2026 at 12:24:45PM -0400, Sasha Levin wrote:
> On Thu, Jul 16, 2026 at 05:08:40PM +0100, Mark Brown wrote:
> >On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
> >> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> >
> >> > - There are many first-time contributors coming in with LLM-generated
> >> >  patches.  At times, I could swear that every one of them is focused on
> >
> >> >  Our maintainers are not scaling to handle this new flood, and I fear we
> >> >  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >> >  recently nearly succeeded in establishing himself as the maintainer of
> >> >  lib/.  How do we hold the line against this stuff while remaining open to
> >> >  new developers?
> >
> >> Shouldn't it be a merits question rather than a tools question?
> >
> >> If the commits are correct, does it matter if they were written with an LLM? we
> >> can insist more on supplying tests and demonstrating correctness, something we
> >> seem to be doing quite rarely right now.
> >
> > The issue (which a number of projects are facing) is as much one of
> > volume as anything else, the code generation machines are enabling the
> > generation and submision of volumes of code where things were previously
> > constrained by human factors.  It can turn into a bit of a DoS.  I don't
> > have any particularly bright ideas here but it's definitely a thing.
> 
> Sure, we're seeing quite the increase in patch submissions, but I'm trying to
> argue that the issue isn't a new one: lack of maintainers, trusted reviewers,
> and maintainer burnout has been a topic at each kernel summit for as long as I
> can remember. AI just kicks it up a notch.
> 
> My concern is that if we focus on the AI aspect, we still won't be solving the
> underlying issue.
> 
> I'm hoping we can figure out how to get maintainers great tooling, testing, and
> community, rather than figuring out how to block a developer who uses LLM.
> Maybe AI would actually be a great catalyst for that as well?

Didn't you argue in another part of this thread that we're in no danger
of being depending on AI for our processes ? I see a contradiction here.

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[James Bottomley]

On Thu, 2026-07-16 at 13:05 -0700, Bart Van Assche wrote:
> 
> On 7/16/26 11:36 AM, Jonathan Corbet wrote:
> > What will we do when the current round of corporate generosity ends
> > and that tool goes away?  Maybe I'm worrying too much, but this
> > does seem, to me, like a possibility we should keep in mind.
> 
> My understanding is that Sashiko is open source and also that it
> supports multiple LLMs. I do not know whether it supports open weight
> LLMs. Roman, please correct me if I got anything wrong.

The corporate generosity isn't the code, it's the free tokens required
to run it on the LLM.  If that free supply dries up, we'll have the
code but won't be able to afford to run it.

Regards,

James

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Theodore Tso]

On Thu, Jul 16, 2026 at 12:36:53PM -0500, Jonathan Corbet wrote:
> The related discussions have featured a number of maintainers talking
> about how much time Sashiko has saved them.  I believe them.  How long
> will it take until nobody does that level of patch review anymore?  What
> will we do when the current round of corporate generosity ends and that
> tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> like a possibility we should keep in mind.

Sashiko finds issues that human reviewers wouldn't necessarily notice.
Before Sashiko, at least for ext4, I'd find those sorts of issues by
running 24 VM hours worth of fstests, and rely on that testing to find
problems that I might miss when doing the initial patch review.  Could
I have found it by spending 3 times as much time looking at each
commit, and thinking deeply?  Sure.  But I don't have the time for
that, so I've *already* relied on Google contributing roughly two
dollars of VM time for each 24 hour regression test run.  Sashiko
might be a bit more expensive on a per-patch basis, but just as I
never viewed fstests as a replacement for human-level review, I don't
think Sashiko is complete substitute human review.

We still need experienced human reviewers to ask whether the fix is
being done in the right place, or whether the right solution is to
*remove* code as opposed to *adding* code, etc.  This is critical if
we want the code to be maintainable in the long-term.  I agree that if
reviewers stop doing this, we would be in a world of hurt --- but that
can happen if people were to start relying on kunit tests passing as a
substitute for code review.

						- Ted