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

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

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