Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

Mark Brown <[email protected]> Thu, 13 Aug 2026 12:48:24 +0100

Newsgroups	dev.linux.lists.ksummit
Message-ID	<[email protected]>

On Thu, Aug 13, 2026 at 06:33:05AM +1000, Dave Airlie wrote:

> So I remember some of the problem, if you cherry-pick with -x the
> complaint was we had commits in -fixes with a cherry-pick commit id
> that wasn't in Linus' tree at that time.

> It would of course later materialise in Linus' tree when the next
> merge window occurred since we don't rebase, but this either broke
> people's brains or scripts badly enough we got push back on it.

> I think we should definitely do -x on all cherry-picks and I'll push
> to make sure we start doing it again.

That'd be helpful, thanks -  I guess you're going to annoy someone
either way unfortunately but at least the commit not in mainline issue
would be transient.

> I'm going to look into giving next a tree with fixes merged into it,
> it's non-trivial even for our dim managed trees which are the main
> drm, drm-misc and intel trees, since currently drm-tip is all of the
> above + CI bandaids, but we could probably construct an offramp in dim
> to create a merged tree using the rerere cache.

Thanks for this also - another idea might be to order the stuff that
isn't for -next at the end of the merge, and push the tree out as a
separate branch before carrying on with the non-next bits (like how
pending-fixes is done)?

signature.asc (application/pgp-signature, 488 B)