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

On Tue, 18 Aug 2026 11:38:08 +0200,
Jani Nikula wrote:
> 
> On Thu, 13 Aug 2026, Mark Brown <[email protected]> wrote:
> > 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.
> 
> We use the drm subsystem maintainer tool for cherry-picks, and it uses
> the -x option.
> 
> If you have any suggestions for helpful but non-intrusive additional
> annotations on cherry-picked commits, it should be easy enough to update
> the tool. And perhaps the annotation could be more widely adopted as
> well. It's not like nobody else ever cherry-picks, we just do it
> more. The annotation could still be the same.

The cherry-pick -x option helps a lot indeed, that's fine, per se.

However, the oddity is that the original commit comes to the upstream
a few weeks later again while the cherry-pick commit got already
merged earlier.  And, of course, the original commit has no notion
showing this is a dup.

So, a single direction cherry-pick solution doesn't suffice, and IMO,
we need to have some reverse-mapping of the aliases.  This could be
some external content or some other way.
(I could think of git-notes, but people won't agree, judging from the
historical development and the implementation of git-notes.)


thanks,

Takashi