Time for drm-ci-next?

[Daniel Vetter]

On Tue, Jul 02, 2024 at 05:32:39AM -0700, Rob Clark wrote:
> 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.

That sounds more like we should push on the drm-misc pre-merge CI boulder
to move it uphill, than add even more trees to make it even harder to get
there long term ...

Short term it helps locally to have finer trees, but only short term and
only very locally.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch