Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood
Laurent Pinchart <[email protected]>
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <[email protected]> |
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/[email protected]/ -- Regards, Laurent Pinchart