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

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

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