Time for drm-ci-next?

[Daniel Vetter]

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 at linux.intel.com> wrote:
> > > > 
> > > > On Thu, 14 Mar 2024, Rob Clark <robdclark at gmail.com> 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