Time for drm-ci-next?

[Rob Clark]

On Fri, Jun 28, 2024 at 10:44 AM Daniel Vetter <daniel at ffwll.ch> wrote:
>
> On Thu, Jun 27, 2024 at 11:51:37AM -0700, Rob Clark wrote:
> > 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).
>
> I guess I'm confused about what kind of pre-merge testing we're talking
> about then ... Or maybe this just doesn't work too well with the linux
> kernel. The model is that you have some pile of trees, they're split up,
> and testing of all the trees together is done in integration trees like
> linux-next or drm-tip.

pre-merge: for msm we've been collecting up patches from list into a
fast-forward MR which triggers CI before merging to msm-next/msm-fixes

Ideally drm-misc and other trees would do similar, we'd catch more
regressions that way.  For example, in msm-next the nodebugfs build is
currently broken, because we merged drm-misc-next at a time when
komeda was broken:

https://gitlab.freedesktop.org/drm/msm/-/jobs/60575681#L9520

If drm-misc was using pre-merge CI this would have been caught and the
offending patch dropped.

BR,
-R

> Criss-cross merging of trees just for integration testing is no-go. And
> that seems to be the only reason you want drm-ci-next?
>
> Also, this sounds more like msm being in a separate tree is the pain point
> here, and solving "we have too many trees" by adding more isn't a good
> idea ...
>
> Or I'm just totally confused.
> -Sima
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch