[rerere PATCH] nightly.conf: Merge drm-msm trees into drm-tip

[Daniel Vetter]

On Fri, Jun 28, 2024 at 12:21:32PM +0300, Jani Nikula wrote:
> On Fri, 28 Jun 2024, Dmitry Baryshkov <dmitry.baryshkov at linaro.org> wrote:
> > On Thu, Jun 27, 2024 at 09:26:19PM GMT, Jani Nikula wrote:
> >> On Thu, 27 Jun 2024, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> >> > On Wed, 26 Jun 2024, Dmitry Baryshkov <dmitry.baryshkov at linaro.org> 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 at gmail.com>
> >> >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
> >> >
> >> > It also helps in avoiding conflicts!
> >> >
> >> > Acked-by: Jani Nikula <jani.nikula at intel.com>
> >> 
> >> 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