Time for drm-ci-next?

[Rob Clark]

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?

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