On Tuesday, February 25th, 2025 at 15:43, Harry Wentland <harry.wentl...@amd.com> wrote:
> > > We need to be a bit careful when merging patches from the same series > > > via multiple trees. Maybe we'll merge the colorop stuff via the amd > > > tree? I don't remember the rules around trees, and I don't know if it > > > would be fine to merge the vkms changes in that tree as well. (I only > > > remember Simona recommending against merging via multiple trees, because > > > it's painful.) > > > > > > If we can't merge the vkms changes via the amd tree, they will likely > > > need to wait for the amd tree to be merged back in drm-next? > > > > > > If we merge some changes via drm-misc-next, then we won't be able to > > > merge the rest via amd, if the rest depends on these changes. > > > > If the drm-*-next branches are synchronized often, I propose to split into > > 4 series: > > - 2/45, in drm-misc-fixes (it is a bug) > > - 3/45, in drm-misc-next (only the vkms part needs it, can be merged just > > after 1 with minor conflict resolution, which I can do) > > - 1, 4..13, 21..45, in drm-amd-next > > - 14..20, in drm-misc-next, once drm-amd-next is merged in drm-misc-next (I > > don't expect huge conflicts if this is merged "soon", afaik nobody is > > currently working on the composition algorithm) > > I would think it's easier if it all goes in via drm-misc next, > except for patch 2 which can be part of drm-misc-fixes. Alex > and I based our branches on drm-misc-next. There shouldn't be > major conflicts with drm/amd code but we can check that before > merging. That sounds like the simplest solution to me :)
