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

Mark Brown <[email protected]> Wed, 12 Aug 2026 00:10:08 +0100
Newsgroups	dev.linux.lists.ksummit
Message-ID	<[email protected]>
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.

> 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.

> Well, I was going to tell about the drm-tip, but that you already know.
> And yes, we cannot have that for-next because it contains topic branches
> we really don't want to send up.

> Dave, Sima, Jani, perhaps we could instrument dim to create a drm-for-next
> that is the merge of all of our relevant branches excluding the topic
> branches?

I think that's in the shape of what I'm suggesting above.
signature.asc (application/pgp-signature, 488 B)