On Tue, Jan 12, 2021 at 06:24:50PM +0200, Jani Nikula wrote: > On Mon, 11 Jan 2021, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote: > > On Mon, Jan 11, 2021 at 12:57:43PM -0800, Matt Roper wrote: > >>On Mon, Jan 11, 2021 at 10:18:45PM +0200, Jani Nikula wrote: > >>So to clarify, it looks like we have a bunch of revid changes to the > >>display code that got merged to the gt-next tree but not to the > >>intel-next tree? Should we be going back and also merging / > >>cherry-picking those over to intel-next since that's where the display > >>changes are supposed to go, or is it too late to do that cleanly at this > >>point? > > > > it was my mistake to merge them to drm-intel-gt-next. They should have > > been in drm-intel-next. > > That's not the problem though. The branches generally being too far > apart atm is. The single cherry-pick won't solve that. Applying these > patches to one tree just adds a dependency that will not be around in > the topic branch baseline, creating a new problem for merging the topic > branch. I still don't understand what the original goal of splitting the driver into two different trees was. It's clear that this approach is going to cause extra mistakes and bugs if we continue down this path and it's not clear to me what the expected benefit was to justify the additional complexity? When are the two branches supposed to be brought back in sync? Is it just a single backmerge to each branch immediately after new mainline kernel releases or is there some other strategy to handle this? Matt > > >>Going forward, what should the general strategy be for stuff like > >>platform definitions and such? Merge such enablement patches to both > > > > last time we talked about this was regarding dg1 AFAIR and the consensus > > was to create a topic branch and that topic branch to be merged in both > > branches. That would avoid having 2 commits in different branches. > > Agreed. > > > Not sure if it would work out nicely for getting test on CI though. > > Since the changes are spread through the codebase, we could very easily > > hit a situation that this topic branch creates conflicts for other > > patches getting merged on either drm-intel-next or drm-intel-gt-next. > > The cycle in review -> apply to topic branch -> merge topic branch just > needs to be short enough. We can't have the topic branch laying around > for more than maybe a few days, or we'll have problems. > > > BR, > Jani. > > -- > Jani Nikula, Intel Open Source Graphics Center -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
