On Mon, Jun 24, 2024 at 10:25:25AM -0300, Helen Koike wrote: > > > On 24/06/2024 02:34, Vignesh Raman wrote: > > Hi, > > > > On 15/03/24 22:50, Rob Clark wrote: > > > 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? Yes, either dedicated topic branch or only backmerging drm-next please, that's how we're handling the flow for all other subtrees too. > > > 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. This sounds more like you want an integration tree like drm-tip. Get msm branches integrated there, done. Backmerges just for integration testing are not a good idea indeed. > > There are many CI patches merged recently to drm-misc-next. > > With the GitLab 18.0 release, CI/CD pipeline configurations must > > transition from using the deprecated CI_JOB_JWT to the new id_tokens > > method, as the former will be removed. > > > > Without the below commit kernel-build job pipelines fail in drm-ci, > > https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/cc806b74466672a9bbd4e9a04265d44eb506b686 > > > > We need to cherry pick only this commit to fix this issue. > > So it would be beneficial to have a drm-ci-next branch. > > > > Regards, > > Vignesh > > > I don't mind using a drm-ci-next branch if it is created. What exactly is the issue in backmerging drm-misc-next (well through drm-next really)? Also if there is an issue, generally we do ad-hoc topic branches. I'm very very skeptical of boutique trees with tiny focus, we've had that before drm-misc, it's a mess. Definitely no enthusiasm for getting back to that kind of world. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
