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

On Wed, 12 Aug 2026 at 09:10, Mark Brown <[email protected]> wrote:
>
> On Tue, Aug 11, 2026 at 03:54:38PM -0400, Rodrigo Vivi wrote:
>
> > 1. Increase the risk of hic-ups in other fronts. For instance: patches
> > that should had been merged to -fixes only going to next and forgotten
> > to be ported to the previous version. And patches that should be new
> > features due to the risk of regression, added to the previous version.
>
> > But here one could argue that in a distributed commit rights flow, this
> > is exactly why maintainers role is more critical, tto ensure we are not
> > missing anything and that the patches are moved to the right place.
> > Fair enough, but this makes our hashes more likely to change. We try
> > to keep the non-rebasing tree to avoid disruptions in OSVs and many
> > other teams that are consuming our trees.
>
> I don't think cherry picking if something gets misdirected would be the
> end of the world, it's more the fact that you're both doing it as the
> normal and default thing and never marking the cherry picks as such that
> causes issues.

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.

>
> > 2. The conflicts would happen anyway. I still see a lot of conflicts
> > in the drm-misc flow.
>
> > 3. Harder to manage the conflicts. Our cherry-pick flow brings some very
> > obvious conflict resolution to the table. If you are in a newer kernel
> > you likely only need to go with it is already in our -next branches,
> > if you are in the current -rc based you likely need to go with what
> > it ported to -fixes. It really is not something complicated to solve.
> > But if you go with a flow that the patches don't have the same baseline
> > like we have the -next and our -tip, then you get harder conflicts to
> > solve and likely to make more mistakes.
>
> The conflicts that I'm seeing from drm are I would say the hardest to
> follow, certainly by far the hardest to follow that I see on such a
> frequent and routine basis.  They are often huge because of the lack of
> shared history between the two branches, there's often enormous sets of
> changes on both sides (not helped by all the unadvertised duplication
> making the divergent histories bigger) and there's no structure or
> explanation for what's going on.  It's all a huge mess, and as a result
> it's the area where I make most mistakes and end up having to do time
> consuming stuff like repeat builds and merges.
>
> You do sometimes see more complicated things, I do occasionally end up
> doing things like just hold a change at an old version and ask for help,
> but it's more like once every couple of releases rather than several
> times a week.  However with those more complicated cases understanding
> what the conflict is tends to be a lot simpler, you can generally see
> the two sets of changes and what they're trying to accomplish quite
> easily, and the complexity comes from colliding semantic changes in an
> unfamiliar area of code.  The fact that with these cases the developers
> concerned are usually surprised to learn of the conflict does help a lot
> too.
>
> I think from a -next point of view the smallest change that would help
> would be if the -next branches you were publishing had all your -fixes
> branches and Linus' tree already merged up up, that way any conflicts
> that do come up would be actual conflicts with other things rather than
> just the rountine conflict spam that should just have been a merge
> instead of a cherry pick in the first place.  I believe that this is
> what happens before the drm changes get sent to Linus.  That wouldn't
> help the stable people (marking the cherry picks would be the smallest
> change for them I think but ICBW?) but I'd guess it would help everyone
> doing merges.  You could always do frequent merges on a separate branch
> and then redo everything for what gets sent to Linus so we don't end up
> with excessive mechanical merges in history.

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.

Dave.