On Fri, Jun 28, 2024 at 12:21:32PM +0300, Jani Nikula wrote: > On Fri, 28 Jun 2024, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On Thu, Jun 27, 2024 at 09:26:19PM GMT, Jani Nikula wrote: > >> On Thu, 27 Jun 2024, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > >> > On Wed, 26 Jun 2024, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > >> >> In order to improve testing of drm/msm branches, add drm-msm trees to > >> >> the list of the trees to be merged into drm-tip. > >> >> > >> >> Cc: Rob Clark <robdclark@xxxxxxxxx> > >> >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > >> > > >> > It also helps in avoiding conflicts! > >> > > >> > Acked-by: Jani Nikula <jani.nikula@xxxxxxxxx> > >> > >> Oh, this is with the assumption that you'll also maintain the branches > >> with dim. I realized this was not spelled out, but I'm hoping it is the > >> case. > > > > No, we use gitlab MRs in order to be able to pre-test patches. But it > > doesn't stop anybody from running dim ub && dim push after merging an > > MR. > > IMO that's not quite enough. > > The main problem with this (from drm-tip and dim POV) is that you won't > notice if you push patches that cause conflicts in rebuilding > drm-tip. That's then left for the next person to figure out, and for > them it's completely unexpected. > > We had this when AMD branches were part of drm-tip, and it really wasn't > much fun, because the burden and benefits were quite lopsided. It's the > main reason the branches were dropped. > > Now, I think there's a non-trivial amount of people who want to see more > of gitlab MR based workflows. This is a problem we'll inevitably need to > tackle anyway. Perhaps rebuilding drm-tip could be a gitlab workflow, > triggered automatically when any of the branches are pushed? With > notifications for folks to figure out the conflicts. Maybe there could > be some linux-next like logic to use older branches until the conflicts > get fixed. Yeah if the gitlab side just pushes without rebuilding drm-tip this isn't going to work well and we'll need to go back. I was thinking that we should be able to run dim rebuild-tip from gitlab CI flows, at least for the cases where everything builds. If you need to fix things up you still need to do a local run. Even better would be if this runs pre-merge so that the MR fails to land if there's new conflicts, but that's a bit more tricky. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch