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

On Fri, Aug 7, 2026 at 3:37 PM Laurent Pinchart
<[email protected]> 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.