(Not) Merging fixes into next

Posted Jan 17, 2025 12:34 UTC (Fri) by geert (subscriber, #98403)
Parent article: The many names of commit 55039832f98c

> If needed, the maintainers of that subsystem may also merge the fixes branch into their "next release" branch.

Not doing this regularly is my main gripe with drm-next.

When merging drm-next and other for-next trees into the latest upstream release, conflicts can be expected, because e.g. a common structure was changed in a different subsystem, or an API was changed, and a new user still expecting the old API popped up. However, in my experience, most of the time when merging drm-next, the conflict is not such an expected conflict, but a conflict with the DRM fixes that had just gone upstream.
Merging their own fixes branch into their own for-next branch before sending a fixes pull request would avoid such conflicts. In the absence of such a merge, every single person who wants to merge drm-next into the latest upstream release has to resolve these conflicts, and has to spend time investigating changes to drivers and/or a subsystem they may not be familiar with.
Fortunately (for me), Stephen Rothwell lives in an earlier time zone, so by the time I start creating a renesas-drivers release, he usually has already created a linux-next release, and thus has already resolved these conflicts himself ;-) Thanks Stephen!

(Not) Merging fixes into next

Posted Jan 17, 2025 20:38 UTC (Fri) by sima (subscriber, #160698) [Link] (3 responses)

This is another issue we've solved almost a decade ago with drm-tip: https://drm.pages.freedesktop.org/maintainer-tools/drm-ti... it both contains the merged tree of a pile of drm branches, and separate branches with fixups patches and git rerere solutions.

We've also imposed resolving new conflicts onto each individual committer (they tend to know best) and then everyone else just reuses the merge resolutions, which is why we're scaling to pretty ridiculous amounts of inter-tree conflicts.

At a ks years ago I think I was discussing with Stephen whether there's any interesting in sharing these in a standardized format, but there was no interest apparently.

(Not) Merging fixes into next

Posted Jan 19, 2025 10:29 UTC (Sun) by geert (subscriber, #98403) [Link] (2 responses)

> This is another issue we've solved almost a decade ago with drm-tip: https://drm.pages.freedesktop.org/maintainer-tools/drm-ti... it both contains the merged tree of a pile of drm branches, and separate branches with fixups patches and git rerere solutions.

Thanks a lot!

I had heard DRM committers have access to shared rerere-resolutions, but didn't know the details (and didn't find it appropriate to ask for DRM commit access just for that ;-) How do you make git consider that branch for resolutions? Is having it as a remote sufficiently, or do you need extra setup or magic? The drm-tip and dim documentation do not describe how it works (not using dim).

I didn't know about drm-tip.
Will give it a try for next renesas-drivers release.

> At a ks years ago I think I was discussing with Stephen whether there's any interesting in sharing these in a standardized format, but there was no interest apparently.

Not everybody is at the Kernel Summit. And even if they are, they might miss that session/information...

(Not) Merging fixes into next

Posted Jan 20, 2025 9:00 UTC (Mon) by sima (subscriber, #160698) [Link]

I think dim does some normalization of branch names (which git puts into the stored resolutions) in the rerere branch to make sure they transfer better. But we've had issues in the past where different git versions aren't entirely compatible due to changes in the merge and diff algorithms iirc. We put in minimal git version checks when we discovered these, but I think hasn't happened in years. So it's not perfect and needed some hacks to make it work reasonably well.

(Not) Merging fixes into next

Posted Jan 20, 2025 9:09 UTC (Mon) by sima (subscriber, #160698) [Link]

Oh and forgot to add for the setup, dim setup adjusts .git/rr-cache to be a symlink to a checkout of that branch for the git tree that does the drm-tip rebuilding.