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

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

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