Time for drm-ci-next?

[Rob Clark]

On Wed, Jun 26, 2024 at 10:47 AM Daniel Vetter <daniel at ffwll.ch> wrote:
>
> On Wed, Jun 26, 2024 at 11:38:30AM +0300, Dmitry Baryshkov wrote:
> > On Wed, Jun 26, 2024 at 09:32:44AM GMT, Daniel Vetter wrote:
> > > 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:
> > > > > > 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.

But AFAIU this doesn't help for pre-merge testing, ie. prior to a
patch landing in msm-next

My idea was to have a drm-ci-next managed similar to drm-misc-next, if
we have needed drm/ci patches we could push them to drm-ci-next, and
then merge that into the driver tree (along with a PR from drm-ci-next
to Dave).

BR,
-R

> >
> > Is it fine to get drm/msm{-fixes,-next} into drm-tip?
>
> Should be.
>
> > > What exactly is the issue in backmerging drm-misc-next (well through
> > > drm-next really)?
> >
> > drm-misc-next is its own tree with separate cadence, its own bugs and
> > misfeatures. But probably just picking up drm-next for the tests should
> > be fine.
>
> Well, more CI should make the situation better for everyone. And I don't
> think you can avoid issues with topic branches, since usually there's
> enough stuff going on that you still often need parts of drm-next. The
> clean topic branches only tend to happen with other subsystems, where the
> interactions are much less.
>
> I think aim for more integration testing first with something like
> drm-tip, one-off topic branches if really needed for e.g. the gitlab
> version upgrade (but still prefer backmerges if that's enough) and see
> where it goes?
>
> If other trees introduce bugs it's imo much better to hit them early than
> in the middle of the next merge window, which is what you'd get with
> maximum amount of topic branches and tree separation. And the merge window
> is already really wobbly, we need to make that better.
>
> Cheers, Sima
>
> > > 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
> >
> > --
> > With best wishes
> > Dmitry
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch