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@xxxxxxxx> 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
