Time for drm-ci-next?

Daniel Vetter daniel at ffwll.ch
Fri Jun 28 17:44:53 UTC 2024


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.

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


More information about the dri-devel mailing list