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). 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