On Fri, Mar 15, 2024 at 2:28 AM Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > > On Thu, 14 Mar 2024, Rob Clark <robdclark@xxxxxxxxx> wrote: > > When we first merged drm/ci I was unsure if it would need it's own > > -next branch. But after using it for a couple releases, a few times > > I've found myself wanting to backmerge drm/ci changes without > > necessarily backmerging all of drm-misc-next. > > > > So, maybe it makes some sense to have a drm-ci-next branch that > > driver-maintainers could back-merge as-needed? > > That's a crossmerge instead of a backmerge, and I feel that could get > messy. What if folks crossmerge drm-ci-next but it gets rejected for > drm-next? Or the baselines are different, and the crossmerge pulls in > way more stuff than it should? Yeah, it would defeat the point a bit of drm-ci-next was on too new of a baseline, the whole point is to be able to merge CI changes without pulling in unrelated changes. So drm-ci-next would need to base on something older, like the previous kernel release tag. > IMO the route should be drm-ci-next -> pull request to drm-next -> > backmerge drm-next to drivers and drm-misc-next. > > I'm not opposed to having drm-ci-next at all, mainly indifferent, but I > question the merge flows. And then the question becomes, does my > suggested merge flow complicate your original goal? > I guess we could avoid merging drm-ci-next until it had been merged into drm-next? Basically, I often find myself needing to merge CI patches on top of msm-next in order to run CI, and then after a clean CI run, reset HEAD back before the merge and force-push. Which isn't really how things should work. BR, -R > > BR, > Jani. > > > -- > Jani Nikula, Intel
