[MAINTAINERS SUMMIT] Coping with the new-developer flood

[MAINTAINERS SUMMIT] Coping with the new-developer flood

[Jonathan Corbet]

This topic came to mind after a rather unsatisfying exchange with a
would-be contributor today.

The 7.1 kernel included work from 530 first-time contributors.  That was
a record - but a short-lived one.  As of -rc6, 7.2 has merged patches
from 565 first-time folks.  A regression to the long-term mean (2-300)
seems unlikely in the near future.

A flood of new contributors may be a high-quality problem, but it still
can be a problem.  We have folks coming in who are unaware of our ways,
are often LLM-driven (without disclosing it), and who may have
objectives that are not entirely compatible with ours.  Maintainers end
up having to educate these people; that is part of a maintainer's job,
but an increase in that work doesn't help people who are already feeling
overwhelmed.

Do we need some sort of more organized onboarding structure and, if so,
are we able to create and sustain it?

At a minimum, one could imagine a bot that notices a patch posted by
somebody who has not been seen before and responds with a "Welcome!
Here's how we do things here" email.  In a better-funded world, we could
consider setting up a small group of folks who reach out to first-time
people, help them to get their work in order, and ensure that they are
connected to the right maintainer.  Note that, for 7.2, the rate of
first-time people is running at about ten per day, so this isn't really
a task for a part-time volunteer.

Improving our handling of new contributors has the potential to turn
more of them into regular, useful contributors while reducing the
training load on maintainers.  But, as can be seen here, I don't have a
lot of great ideas for how to do that.  Maybe others are more
imaginative?

jon

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Matthieu Baerts]

Hi Jon,

On 06/08/2026 01:26, Jonathan Corbet wrote:
> Do we need some sort of more organized onboarding structure and, if so,
> are we able to create and sustain it?

Good idea to find solutions to reduce the training load on maintainers!

> At a minimum, one could imagine a bot that notices a patch posted by
> somebody who has not been seen before and responds with a "Welcome!
> Here's how we do things here" email.

FYI, that's what the Netdev maintainers are already doing to cope with
the high load:

https://github.com/linux-netdev/nipa/blob/main/ml-agent/form-letters/welcome

This part should be re-usable to work on other trees, monitoring other
mailing lists (public-inboxes to be precise). But I guess it would be
easier to have something global, instead of asking each subtree
maintainer to set all that up.

> In a better-funded world, we could

So many things we could do in this world :)

(BTW, that's a shame there is no "kernel foundation" within the Linux
Foundation, where the TAB could quickly allocate budgets to improve
various things, helping maintainers in different areas like tooling, CI,
funding, local AI, documentation, regression, etc. But that's another
subject :) )

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Dan Carpenter]

A lot of first time developers start in driver/staging where I review
patches.  I had to re-edit my "How to Send a v2" instructions to
really emphasize not to resend a patch series that same day.  Otherwise
it feels like you are pair programming instead of a reviewer.

https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/

regards,
dan carpenter

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Theodore Tso]

On Wed, Aug 05, 2026 at 05:26:11PM -0500, Jonathan Corbet wrote:
> Do we need some sort of more organized onboarding structure and, if so,
> are we able to create and sustain it?
> 
> At a minimum, one could imagine a bot that notices a patch posted by
> somebody who has not been seen before and responds with a "Welcome!
> Here's how we do things here" email.

I wonder if we could make the bot more sophisticated than just sending
a welcome message.  If the patch is white-space damaged, or doesn't
apply against upstream (or if there are indications that it was
applied against an LTS branch without an explicit LTS tag or something
indicating that it is a backport), one could imagine having the bot
sending a newer contributor a more specific set of constructive
criticisms.

Some, of this could, perhaps be something that we could add to
Sashiko, with an eye towards giving a more friendly message.  Just
today I had to let a new submitter know that they had sent a
white-space damaged patch, and given they were using a gmail.com
e-mail address, it could be possible to send a more useful message.
(Since I was in a hurry, I just pointed them at the Submitting Patches
document, which is rather long.  :-)

					- Ted

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Greg KH]

On Thu, Aug 06, 2026 at 11:42:33AM -0400, Theodore Tso wrote:
> On Wed, Aug 05, 2026 at 05:26:11PM -0500, Jonathan Corbet wrote:
> > Do we need some sort of more organized onboarding structure and, if so,
> > are we able to create and sustain it?
> > 
> > At a minimum, one could imagine a bot that notices a patch posted by
> > somebody who has not been seen before and responds with a "Welcome!
> > Here's how we do things here" email.
> 
> I wonder if we could make the bot more sophisticated than just sending
> a welcome message.  If the patch is white-space damaged, or doesn't
> apply against upstream (or if there are indications that it was
> applied against an LTS branch without an explicit LTS tag or something
> indicating that it is a backport), one could imagine having the bot
> sending a newer contributor a more specific set of constructive
> criticisms.
> 
> Some, of this could, perhaps be something that we could add to
> Sashiko, with an eye towards giving a more friendly message.  Just
> today I had to let a new submitter know that they had sent a
> white-space damaged patch, and given they were using a gmail.com
> e-mail address, it could be possible to send a more useful message.
> (Since I was in a hurry, I just pointed them at the Submitting Patches
> document, which is rather long.  :-)

I have a much-used "bot" that I use for the "common" problems with
patches sent to my subsystems.  Here's the raw text below if others want
to cut/paste from it and adapt it for their subsystems.

----------------------


Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch breaks the build.

- Your patch contains warnings and/or errors noticed by the
  scripts/checkpatch.pl tool.

- Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
  and can not be applied.  Please read the file,
  Documentation/process/email-clients.rst in order to fix this.

- Your patch was attached, please place it inline so that it can be
  applied directly from the email message itself.

- Your patch does not have a Signed-off-by: line.  Please read the
  kernel file, Documentation/process/submitting-patches.rst and resend
  it after adding that line.  Note, the line needs to be in the body of
  the email, before the patch, not at the bottom of the patch or in the
  email signature.

- Your patch was sent privately to Greg.  Kernel development is done in
  public, please always cc: a public mailing list with a patch
  submission.  Using the tool, scripts/get_maintainer.pl on the patch
  will tell you what mailing list to cc.

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

- Your patch did not apply to any known trees that Greg is in control
  of.  Possibly this is because you made it against Linus's tree, not
  the linux-next tree, which is where all of the development for the
  next version of the kernel is at.  Please refresh your patch against
  the linux-next tree, or even better yet, the development tree
  specified in the MAINTAINERS file for the subsystem you are submitting
  a patch for, and resend it.

- You sent multiple patches, yet no indication of which ones should be
  applied in which order.  Greg could just guess, but if you are
  receiving this email, he guessed wrong and the patches didn't apply.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/process/submitting-patches.rst for a
  description of how to do this so that Greg has a chance to apply these
  correctly.

- You did not specify a description of why the patch is needed, or
  possibly, any description at all, in the email body.  Please read the
  section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what is needed in
  order to properly describe the change.

- You did not write a descriptive Subject: for the patch, allowing Greg,
  and everyone else, to know what this patch is all about.  Please read
  the section entitled "The canonical patch format" in the kernel file,
  Documentation/process/submitting-patches.rst for what a proper
  Subject: line should look like.

- It looks like you did not use your "real" name for the patch on either
  the Signed-off-by: line, or the From: line (both of which have to
  match).  Please read the kernel file,
  Documentation/process/submitting-patches.rst for how to do this
  correctly.

- This looks like a new version of a previously submitted patch, but you
  did not list below the --- line any changes from the previous version.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/process/submitting-patches.rst for what
  needs to be done here to properly describe this.

- You sent a patch that has been sent multiple times in the past few
  days, and is identical to ones that has been recently rejected.
  Please always look at the mailing list traffic to determine if you are
  duplicating other people's work.

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Konstantin Ryabitsev]

On Thu, Aug 06, 2026 at 05:57:54PM +0200, Greg KH wrote:
> > > At a minimum, one could imagine a bot that notices a patch posted by
> > > somebody who has not been seen before and responds with a "Welcome!
> > > Here's how we do things here" email.

I can probably do this, since I run a bunch of bots on list messages already
and this seems like a service that would benefit all subsystems.

> > I wonder if we could make the bot more sophisticated than just sending
> > a welcome message.  If the patch is white-space damaged, or doesn't
> > apply against upstream (or if there are indications that it was
> > applied against an LTS branch without an explicit LTS tag or something
> > indicating that it is a backport), one could imagine having the bot
> > sending a newer contributor a more specific set of constructive
> > criticisms.

Preferably, this would be purely deterministic, such as:

- carries "base-commit"
- has a signed-off-by
- actually applies
- isn't against a known LTS branch

Failing all these on top of being an unknown/new developer could trigger a
quick "here's what you did wrong, oh and welcome btw."

-K

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Shuah Khan]

On 8/6/26 11:28, Konstantin Ryabitsev wrote:
> On Thu, Aug 06, 2026 at 05:57:54PM +0200, Greg KH wrote:
>>>> At a minimum, one could imagine a bot that notices a patch posted by
>>>> somebody who has not been seen before and responds with a "Welcome!
>>>> Here's how we do things here" email.
> 
> I can probably do this, since I run a bunch of bots on list messages already
> and this seems like a service that would benefit all subsystems.

That is great. I am hoping we can do this as a service for all subsystems
as a project wide thing.

> 
>>> I wonder if we could make the bot more sophisticated than just sending
>>> a welcome message.  If the patch is white-space damaged, or doesn't
>>> apply against upstream (or if there are indications that it was
>>> applied against an LTS branch without an explicit LTS tag or something
>>> indicating that it is a backport), one could imagine having the bot
>>> sending a newer contributor a more specific set of constructive
>>> criticisms.
> 
> Preferably, this would be purely deterministic, such as:
> 
> - carries "base-commit"
> - has a signed-off-by
> - actually applies
> - isn't against a known LTS branch
> 
> Failing all these on top of being an unknown/new developer could trigger a
> quick "here's what you did wrong, oh and welcome btw."

This looks a good start and we can improve it as we go.

thanks,
-- Shuah

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Dan Carpenter]

On Thu, Aug 06, 2026 at 01:28:25PM -0400, Konstantin Ryabitsev wrote:
> - actually applies
> - isn't against a known LTS branch

No one wants patches against an LTS branch.  That would violate the
stable rules since everything should be upstream first.

Most subsystems take patches against -next and backport the Fixes.
A couple have a tree for the -rc branch and want patches that apply
specifically to that.  These are net, bpf and certain Intel networking
drivers.  These three subsystems want people to put in the subject
which tree they are working against like [PATCH net-next]"

Everyone else pretty much accepts patches against linux-next.  In staging
we tell people to work against staging-next but working against linux-next
is fine.  It's basically the same thing.

regards,
dan carpenter

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Mark Brown]

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

On Thu, Aug 06, 2026 at 10:32:40PM +0300, Dan Carpenter wrote:

> Most subsystems take patches against -next and backport the Fixes.
> A couple have a tree for the -rc branch and want patches that apply
> specifically to that.  These are net, bpf and certain Intel networking
> drivers.  These three subsystems want people to put in the subject
> which tree they are working against like [PATCH net-next]"

I think it's at least as common if not more common to take fixes against
Linus' tree or the tree's current fixes branch and then merge them up
into the development code as needed.  There are a few trees constantly
cherry picking things around but it's a very small proportion of trees.

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

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Theodore Tso]

On Thu, Aug 06, 2026 at 10:32:40PM -0500, Dan Carpenter wrote:
> On Thu, Aug 06, 2026 at 01:28:25PM -0400, Konstantin Ryabitsev wrote:
> > - actually applies
> > - isn't against a known LTS branch
> 
> No one wants patches against an LTS branch.  That would violate the
> stable rules since everything should be upstream first.

Right, we should issue a warning if it's not a backport from upstream
(e.g., if it's against an LTS branch, it should have an
Upstream-commit: tag).

There are some few exceptions, where a fix can't be easily backported
to the LTS branch, and so a different way of fixing a particular
serious patch needs to be applied to the LTS branch.  But normally
this will be explicitly stated in the commit description, but we don't
do that in a structured way, so it might be hard for a non-LLM bot to
figure this out.  On the other hand, this is a pretty advanced
technique, and it's unlikely that a new kernel developer would be
doing something like this.  So we probably just ignore this case for a
newcomers-focused bot.

						- Ted

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Matthieu Baerts]

Hi Ted, Dan, Konstantin,

On 07/08/2026 05:23, Theodore Tso wrote:
> There are some few exceptions, where a fix can't be easily backported
> to the LTS branch, and so a different way of fixing a particular
> serious patch needs to be applied to the LTS branch.  But normally
> this will be explicitly stated in the commit description, but we don't
> do that in a structured way, so it might be hard for a non-LLM bot to
> figure this out.
Good point, but instead of looking at the patch description, it might be
enough to look at the header: an exception could be added for patches
sent to the stable ML with a version in the prefix.

But back to the idea of checking if the patch can apply: it might not be
easy to deal with all the different trees and branches. There might be
some dependences that are still in review, or applied somewhere but not
in linux-next yet, or conflicts with linux-next, etc. Plus note that
Sashiko will generally complain if it cannot find where to apply it.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Laurent Pinchart]

On Fri, Aug 07, 2026 at 11:20:39AM +0200, Matthieu Baerts wrote:
> On 07/08/2026 05:23, Theodore Tso wrote:
> > There are some few exceptions, where a fix can't be easily backported
> > to the LTS branch, and so a different way of fixing a particular
> > serious patch needs to be applied to the LTS branch.  But normally
> > this will be explicitly stated in the commit description, but we don't
> > do that in a structured way, so it might be hard for a non-LLM bot to
> > figure this out.
> 
> Good point, but instead of looking at the patch description, it might be
> enough to look at the header: an exception could be added for patches
> sent to the stable ML with a version in the prefix.
> 
> But back to the idea of checking if the patch can apply: it might not be
> easy to deal with all the different trees and branches. There might be
> some dependences that are still in review, or applied somewhere but not
> in linux-next yet, or conflicts with linux-next, etc.

This is an issue that isn't limited to newcomers. As a maintainer, I
sometimes don't know what I should apply a patch series on. We have the
base-commit and prerequisite-patch-id trailers added by b4 that help a
lot there, but not everybody uses them. If a mechanism that flags the
issue for newcomers could also ensure that every patch series carries
proper base information, that would be a very nice side effect. This may
include adding new trailers if some use cases are not currently covered.

> Plus note that
> Sashiko will generally complain if it cannot find where to apply it.

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[James Bottomley]

On Fri, 2026-08-07 at 14:56 +0300, Laurent Pinchart wrote:
> On Fri, Aug 07, 2026 at 11:20:39AM +0200, Matthieu Baerts wrote:
> > On 07/08/2026 05:23, Theodore Tso wrote:
> > > There are some few exceptions, where a fix can't be easily
> > > backported to the LTS branch, and so a different way of fixing a
> > > particular serious patch needs to be applied to the LTS branch. 
> > > But normally this will be explicitly stated in the commit
> > > description, but we don't do that in a structured way, so it
> > > might be hard for a non-LLM bot to figure this out.
> > 
> > Good point, but instead of looking at the patch description, it
> > might be enough to look at the header: an exception could be added
> > for patches sent to the stable ML with a version in the prefix.
> > 
> > But back to the idea of checking if the patch can apply: it might
> > not be easy to deal with all the different trees and branches.
> > There might be some dependences that are still in review, or
> > applied somewhere but not in linux-next yet, or conflicts with
> > linux-next, etc.
> 
> This is an issue that isn't limited to newcomers. As a maintainer, I
> sometimes don't know what I should apply a patch series on. We have
> the base-commit and prerequisite-patch-id trailers added by b4 that
> help a lot there, but not everybody uses them. If a mechanism that
> flags the issue for newcomers could also ensure that every patch
> series carries proper base information, that would be a very nice
> side effect. This may include adding new trailers if some use cases
> are not currently covered.

There are two reasons not to insist too rigidly on base commit: firstly
because a lot of series are invariant (they apply to any tree because
there's been no commits in the areas patched) and secondly because the
series has a dependency on another posted but not yet applied patch
series (i.e. no published base commit at all).  At least make it a
Maintainer decision whether to insist on base commit or not.

Regards,

James

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Laurent Pinchart]

On Fri, Aug 07, 2026 at 08:28:08AM -0400, James Bottomley wrote:
> On Fri, 2026-08-07 at 14:56 +0300, Laurent Pinchart wrote:
> > On Fri, Aug 07, 2026 at 11:20:39AM +0200, Matthieu Baerts wrote:
> > > On 07/08/2026 05:23, Theodore Tso wrote:
> > > > There are some few exceptions, where a fix can't be easily
> > > > backported to the LTS branch, and so a different way of fixing a
> > > > particular serious patch needs to be applied to the LTS branch. 
> > > > But normally this will be explicitly stated in the commit
> > > > description, but we don't do that in a structured way, so it
> > > > might be hard for a non-LLM bot to figure this out.
> > > 
> > > Good point, but instead of looking at the patch description, it
> > > might be enough to look at the header: an exception could be added
> > > for patches sent to the stable ML with a version in the prefix.
> > > 
> > > But back to the idea of checking if the patch can apply: it might
> > > not be easy to deal with all the different trees and branches.
> > > There might be some dependences that are still in review, or
> > > applied somewhere but not in linux-next yet, or conflicts with
> > > linux-next, etc.
> > 
> > This is an issue that isn't limited to newcomers. As a maintainer, I
> > sometimes don't know what I should apply a patch series on. We have
> > the base-commit and prerequisite-patch-id trailers added by b4 that
> > help a lot there, but not everybody uses them. If a mechanism that
> > flags the issue for newcomers could also ensure that every patch
> > series carries proper base information, that would be a very nice
> > side effect. This may include adding new trailers if some use cases
> > are not currently covered.
> 
> There are two reasons not to insist too rigidly on base commit: firstly
> because a lot of series are invariant (they apply to any tree because
> there's been no commits in the areas patched)

Then the author could pick any base commit available in Linus' tree
the relevant subsystem tree (typically an upstream release of the next
branch of the subsystem). Would that have any drawback compared to not
specifying any base commit at all ?

> and secondly because the
> series has a dependency on another posted but not yet applied patch
> series (i.e. no published base commit at all).  At least make it a
> Maintainer decision whether to insist on base commit or not.

Isn't that what prerequisite-patch-id is for ?

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Arnaldo Carvalho de Melo]

On Fri, Aug 07, 2026 at 03:40:17PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 07, 2026 at 08:28:08AM -0400, James Bottomley wrote:
> > On Fri, 2026-08-07 at 14:56 +0300, Laurent Pinchart wrote:
> > > On Fri, Aug 07, 2026 at 11:20:39AM +0200, Matthieu Baerts wrote:
> > > > On 07/08/2026 05:23, Theodore Tso wrote:
> > > > > There are some few exceptions, where a fix can't be easily
> > > > > backported to the LTS branch, and so a different way of fixing a
> > > > > particular serious patch needs to be applied to the LTS branch. 
> > > > > But normally this will be explicitly stated in the commit
> > > > > description, but we don't do that in a structured way, so it
> > > > > might be hard for a non-LLM bot to figure this out.
> > > > 
> > > > Good point, but instead of looking at the patch description, it
> > > > might be enough to look at the header: an exception could be added
> > > > for patches sent to the stable ML with a version in the prefix.
> > > > 
> > > > But back to the idea of checking if the patch can apply: it might
> > > > not be easy to deal with all the different trees and branches.
> > > > There might be some dependences that are still in review, or
> > > > applied somewhere but not in linux-next yet, or conflicts with
> > > > linux-next, etc.
> > > 
> > > This is an issue that isn't limited to newcomers. As a maintainer, I
> > > sometimes don't know what I should apply a patch series on. We have
> > > the base-commit and prerequisite-patch-id trailers added by b4 that
> > > help a lot there, but not everybody uses them. If a mechanism that
> > > flags the issue for newcomers could also ensure that every patch
> > > series carries proper base information, that would be a very nice
> > > side effect. This may include adding new trailers if some use cases
> > > are not currently covered.
> > 
> > There are two reasons not to insist too rigidly on base commit: firstly
> > because a lot of series are invariant (they apply to any tree because
> > there's been no commits in the areas patched)
> 
> Then the author could pick any base commit available in Linus' tree
> the relevant subsystem tree (typically an upstream release of the next
> branch of the subsystem). Would that have any drawback compared to not
> specifying any base commit at all ?

What if for some reason someone wants to apply it to some base that is
before the one specified? That person would be mislead into thinking
that wouldn't be possible or automation would refuse to do so?

I think if it is _strictly_ need to use some specific base commit, then
that is a requirement, no?

- Arnaldo
 
> > and secondly because the
> > series has a dependency on another posted but not yet applied patch
> > series (i.e. no published base commit at all).  At least make it a
> > Maintainer decision whether to insist on base commit or not.
> 
> Isn't that what prerequisite-patch-id is for ?
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Laurent Pinchart]

On Fri, Aug 07, 2026 at 09:47:43AM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Aug 07, 2026 at 03:40:17PM +0300, Laurent Pinchart wrote:
> > On Fri, Aug 07, 2026 at 08:28:08AM -0400, James Bottomley wrote:
> > > On Fri, 2026-08-07 at 14:56 +0300, Laurent Pinchart wrote:
> > > > On Fri, Aug 07, 2026 at 11:20:39AM +0200, Matthieu Baerts wrote:
> > > > > On 07/08/2026 05:23, Theodore Tso wrote:
> > > > > > There are some few exceptions, where a fix can't be easily
> > > > > > backported to the LTS branch, and so a different way of fixing a
> > > > > > particular serious patch needs to be applied to the LTS branch. 
> > > > > > But normally this will be explicitly stated in the commit
> > > > > > description, but we don't do that in a structured way, so it
> > > > > > might be hard for a non-LLM bot to figure this out.
> > > > > 
> > > > > Good point, but instead of looking at the patch description, it
> > > > > might be enough to look at the header: an exception could be added
> > > > > for patches sent to the stable ML with a version in the prefix.
> > > > > 
> > > > > But back to the idea of checking if the patch can apply: it might
> > > > > not be easy to deal with all the different trees and branches.
> > > > > There might be some dependences that are still in review, or
> > > > > applied somewhere but not in linux-next yet, or conflicts with
> > > > > linux-next, etc.
> > > > 
> > > > This is an issue that isn't limited to newcomers. As a maintainer, I
> > > > sometimes don't know what I should apply a patch series on. We have
> > > > the base-commit and prerequisite-patch-id trailers added by b4 that
> > > > help a lot there, but not everybody uses them. If a mechanism that
> > > > flags the issue for newcomers could also ensure that every patch
> > > > series carries proper base information, that would be a very nice
> > > > side effect. This may include adding new trailers if some use cases
> > > > are not currently covered.
> > > 
> > > There are two reasons not to insist too rigidly on base commit: firstly
> > > because a lot of series are invariant (they apply to any tree because
> > > there's been no commits in the areas patched)
> > 
> > Then the author could pick any base commit available in Linus' tree
> > the relevant subsystem tree (typically an upstream release of the next
> > branch of the subsystem). Would that have any drawback compared to not
> > specifying any base commit at all ?
> 
> What if for some reason someone wants to apply it to some base that is
> before the one specified? That person would be mislead into thinking
> that wouldn't be possible or automation would refuse to do so?
> 
> I think if it is _strictly_ need to use some specific base commit, then
> that is a requirement, no?

It depends on how we interpret the trailers. base-commit is generated by
b4, and I understand it as meaning the submitter used the specified
commit as a base. It doesn't have to mean that maintainers have to apply
the series on that exact base. Compared to having no base specified, it
tells what base the series *can* apply to. I think that's useful
information.

> > > and secondly because the
> > > series has a dependency on another posted but not yet applied patch
> > > series (i.e. no published base commit at all).  At least make it a
> > > Maintainer decision whether to insist on base commit or not.
> > 
> > Isn't that what prerequisite-patch-id is for ?

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Rafael J. Wysocki (Intel)]

On Fri, Aug 7, 2026 at 3:37 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Fri, Aug 07, 2026 at 09:47:43AM -0300, Arnaldo Carvalho de Melo wrote:
> > On Fri, Aug 07, 2026 at 03:40:17PM +0300, Laurent Pinchart wrote:
> > > On Fri, Aug 07, 2026 at 08:28:08AM -0400, James Bottomley wrote:
> > > > On Fri, 2026-08-07 at 14:56 +0300, Laurent Pinchart wrote:
> > > > > On Fri, Aug 07, 2026 at 11:20:39AM +0200, Matthieu Baerts wrote:
> > > > > > On 07/08/2026 05:23, Theodore Tso wrote:
> > > > > > > There are some few exceptions, where a fix can't be easily
> > > > > > > backported to the LTS branch, and so a different way of fixing a
> > > > > > > particular serious patch needs to be applied to the LTS branch.
> > > > > > > But normally this will be explicitly stated in the commit
> > > > > > > description, but we don't do that in a structured way, so it
> > > > > > > might be hard for a non-LLM bot to figure this out.
> > > > > >
> > > > > > Good point, but instead of looking at the patch description, it
> > > > > > might be enough to look at the header: an exception could be added
> > > > > > for patches sent to the stable ML with a version in the prefix.
> > > > > >
> > > > > > But back to the idea of checking if the patch can apply: it might
> > > > > > not be easy to deal with all the different trees and branches.
> > > > > > There might be some dependences that are still in review, or
> > > > > > applied somewhere but not in linux-next yet, or conflicts with
> > > > > > linux-next, etc.
> > > > >
> > > > > This is an issue that isn't limited to newcomers. As a maintainer, I
> > > > > sometimes don't know what I should apply a patch series on. We have
> > > > > the base-commit and prerequisite-patch-id trailers added by b4 that
> > > > > help a lot there, but not everybody uses them. If a mechanism that
> > > > > flags the issue for newcomers could also ensure that every patch
> > > > > series carries proper base information, that would be a very nice
> > > > > side effect. This may include adding new trailers if some use cases
> > > > > are not currently covered.
> > > >
> > > > There are two reasons not to insist too rigidly on base commit: firstly
> > > > because a lot of series are invariant (they apply to any tree because
> > > > there's been no commits in the areas patched)
> > >
> > > Then the author could pick any base commit available in Linus' tree
> > > the relevant subsystem tree (typically an upstream release of the next
> > > branch of the subsystem). Would that have any drawback compared to not
> > > specifying any base commit at all ?
> >
> > What if for some reason someone wants to apply it to some base that is
> > before the one specified? That person would be mislead into thinking
> > that wouldn't be possible or automation would refuse to do so?
> >
> > I think if it is _strictly_ need to use some specific base commit, then
> > that is a requirement, no?
>
> It depends on how we interpret the trailers. base-commit is generated by
> b4, and I understand it as meaning the submitter used the specified
> commit as a base.

That is also my understanding of it.

> It doesn't have to mean that maintainers have to apply
> the series on that exact base. Compared to having no base specified, it
> tells what base the series *can* apply to.

A bit more than this IMV: This is the tree that the series has been
developed against.

So, for instance, it may be used by bots like Sashiko as a reference point.

> I think that's useful information.

Agreed.

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Miguel Ojeda]

On Fri, Aug 7, 2026 at 4:01 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> It depends on how we interpret the trailers. base-commit is generated by
> b4, and I understand it as meaning the submitter used the specified
> commit as a base. It doesn't have to mean that maintainers have to apply
> the series on that exact base. Compared to having no base specified, it
> tells what base the series *can* apply to. I think that's useful
> information.

Yeah, it is very useful when things do not apply cleanly.

By the way, `git format-patch --base` generates it (and the
`prerequisite-patch-id`s), for those not using b4.

Cheers,
Miguel

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[James Bottomley]

On Fri, 2026-08-07 at 15:40 +0300, Laurent Pinchart wrote:
> On Fri, Aug 07, 2026 at 08:28:08AM -0400, James Bottomley wrote:
[...]
> > There are two reasons not to insist too rigidly on base commit:
> > firstly because a lot of series are invariant (they apply to any
> > tree because there's been no commits in the areas patched)
> 
> Then the author could pick any base commit available in Linus' tree
> the relevant subsystem tree (typically an upstream release of the
> next branch of the subsystem). Would that have any drawback compared
> to not specifying any base commit at all ?

It's just pointless hassle given the maintainer workflow is ignore the
base commit and do git (or b4) am on the current branch and only if
that rejects either try and upport based on the base commit or ask for
a respin (the latter being the most common course of action).

> > and secondly because the series has a dependency on another posted
> > but not yet applied patch series (i.e. no published base commit at
> > all).  At least make it a Maintainer decision whether to insist on
> > base commit or not.
> 
> Isn't that what prerequisite-patch-id is for ?

Dear god, absolutely not.  I can't match a patch hash to a series, I
want the lore link of the prerequisite series in the cover letter.

Regards,

James

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Laurent Pinchart]

On Fri, Aug 07, 2026 at 08:51:50AM -0400, James Bottomley wrote:
> On Fri, 2026-08-07 at 15:40 +0300, Laurent Pinchart wrote:
> > On Fri, Aug 07, 2026 at 08:28:08AM -0400, James Bottomley wrote:
> [...]
> > > There are two reasons not to insist too rigidly on base commit:
> > > firstly because a lot of series are invariant (they apply to any
> > > tree because there's been no commits in the areas patched)
> > 
> > Then the author could pick any base commit available in Linus' tree
> > the relevant subsystem tree (typically an upstream release of the
> > next branch of the subsystem). Would that have any drawback compared
> > to not specifying any base commit at all ?
> 
> It's just pointless hassle given the maintainer workflow is ignore the
> base commit and do git (or b4) am on the current branch and only if
> that rejects either try and upport based on the base commit or ask for
> a respin (the latter being the most common course of action).
> 
> > > and secondly because the series has a dependency on another posted
> > > but not yet applied patch series (i.e. no published base commit at
> > > all).  At least make it a Maintainer decision whether to insist on
> > > base commit or not.
> > 
> > Isn't that what prerequisite-patch-id is for ?
> 
> Dear god, absolutely not.  I can't match a patch hash to a series, I
> want the lore link of the prerequisite series in the cover letter.

I thought lore was indexable by patch-id as well, maybe I'm mistaken. If
that's not the case, it could be a useful feature.

The message-id of a prerequisite series is certainly better. There's
apparently a b4 trailer for that, prerequisite-message-id. See [1] for
an example. I don't know how automated, or automatable, adding that
trailer is.

[1] https://lore.kernel.org/lkml/20260805-tegra264-pcie-v9-0-fa2ed7350ae1@nvidia.com/

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Mark Brown]

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

On Fri, Aug 07, 2026 at 08:51:50AM -0400, James Bottomley wrote:
> On Fri, 2026-08-07 at 15:40 +0300, Laurent Pinchart wrote:

> > Then the author could pick any base commit available in Linus' tree
> > the relevant subsystem tree (typically an upstream release of the
> > next branch of the subsystem). Would that have any drawback compared
> > to not specifying any base commit at all ?

> It's just pointless hassle given the maintainer workflow is ignore the
> base commit and do git (or b4) am on the current branch and only if
> that rejects either try and upport based on the base commit or ask for
> a respin (the latter being the most common course of action).

While I routinely don't actually use the base-commit that people provide
it does come in very handy whenever it's hard to work out how to apply
their patches, obviously you can ask what something is based on but it's
easier if the information is just there.  I'm not sure it's worth doing
by hand but it's a great thing to have in tooling.

> > > and secondly because the series has a dependency on another posted
> > > but not yet applied patch series (i.e. no published base commit at
> > > all).  At least make it a Maintainer decision whether to insist on
> > > base commit or not.

> > Isn't that what prerequisite-patch-id is for ?

> Dear god, absolutely not.  I can't match a patch hash to a series, I
> want the lore link of the prerequisite series in the cover letter.

The lore link plus something like the title of the series/patch so the
mail can actually be read directly and you don't have to open a browser
to figure out what the submitter is talking about.

I assume at some point it'll be possible to do something automatically
with the patch IDs at some point.

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

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Mimi Zohar]

On Thu, 2026-08-06 at 23:23 -0400, Theodore Tso wrote:
> On Thu, Aug 06, 2026 at 10:32:40PM -0500, Dan Carpenter wrote:
> > On Thu, Aug 06, 2026 at 01:28:25PM -0400, Konstantin Ryabitsev wrote:
> > > - actually applies
> > > - isn't against a known LTS branch
> > 
> > No one wants patches against an LTS branch.  That would violate the
> > stable rules since everything should be upstream first.
> 
> Right, we should issue a warning if it's not a backport from upstream
> (e.g., if it's against an LTS branch, it should have an
> Upstream-commit: tag).
> 
> There are some few exceptions, where a fix can't be easily backported
> to the LTS branch, and so a different way of fixing a particular
> serious patch needs to be applied to the LTS branch.  But normally
> this will be explicitly stated in the commit description, but we don't
> do that in a structured way, so it might be hard for a non-LLM bot to
> figure this out.  On the other hand, this is a pretty advanced
> technique, and it's unlikely that a new kernel developer would be
> doing something like this.  So we probably just ignore this case for a
> newcomers-focused bot.

Hi Ted,

I have a patch that doesn't need to be upstreamed, as per Eric Bigger's
comment[1], but needs to be in stable kernels.  What is the process for doing
that.

[1]https://lore.kernel.org/linux-integrity/0c590f6c-8ab0-f0ed-25a8-fa8a2ec6008e@huawei.com/

thanks,

Mimi

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Dan Carpenter]

On Fri, Aug 07, 2026 at 09:02:14AM -0400, Mimi Zohar wrote:
> On Thu, 2026-08-06 at 23:23 -0400, Theodore Tso wrote:
> > On Thu, Aug 06, 2026 at 10:32:40PM -0500, Dan Carpenter wrote:
> > > On Thu, Aug 06, 2026 at 01:28:25PM -0400, Konstantin Ryabitsev wrote:
> > > > - actually applies
> > > > - isn't against a known LTS branch
> > > 
> > > No one wants patches against an LTS branch.  That would violate the
> > > stable rules since everything should be upstream first.
> > 
> > Right, we should issue a warning if it's not a backport from upstream
> > (e.g., if it's against an LTS branch, it should have an
> > Upstream-commit: tag).
> > 
> > There are some few exceptions, where a fix can't be easily backported
> > to the LTS branch, and so a different way of fixing a particular
> > serious patch needs to be applied to the LTS branch.  But normally
> > this will be explicitly stated in the commit description, but we don't
> > do that in a structured way, so it might be hard for a non-LLM bot to
> > figure this out.  On the other hand, this is a pretty advanced
> > technique, and it's unlikely that a new kernel developer would be
> > doing something like this.  So we probably just ignore this case for a
> > newcomers-focused bot.
> 
> Hi Ted,
> 
> I have a patch that doesn't need to be upstreamed, as per Eric Bigger's
> comment[1], but needs to be in stable kernels.  What is the process for doing
> that.
> 
> [1]https://lore.kernel.org/linux-integrity/0c590f6c-8ab0-f0ed-25a8-fa8a2ec6008e@huawei.com/
> 

Send a patch to stable@vger.kernel.org with an commit message that
explains why it isn't needed upstream.

regards,
dan carpenter

Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood

[Miguel Ojeda]

On Fri, Aug 7, 2026 at 3:32 PM Dan Carpenter <error27@gmail.com> wrote:
>
> Send a patch to stable@vger.kernel.org with an commit message that
> explains why it isn't needed upstream.

Yeah, please see:

  https://docs.kernel.org/process/stable-kernel-rules.html

In particular last paragraph in Option 3.

Cheers,
Miguel