Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAPM=9tzJQ+26n_Df1eBPG1A=tXf4xNuVEjbG3aZj-aqYQ9nnAg@mail.gmail.com>
 <CAPM=9tx+CEkzmLZ-93GZmde9xzJ_rw3PJZxFu_pjZJc7KM5f-w@mail.gmail.com>
 <20190715122924.GA15202@mellanox.com> <CAKMK7uHvjuQ5Dqm0LPrtQxdHh5Z6Pt2mg4AnpRRR0gWb1Wp05g@mail.gmail.com>
 <20190715150402.GD15202@mellanox.com>
In-Reply-To: <20190715150402.GD15202@mellanox.com>
From:   Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon, 15 Jul 2019 19:53:06 +0200
Message-ID: <CAKMK7uGbNuA_pN=r9XKGz2MTVVJWm6q8tKBT3WJPa93nKEe4iA@mail.gmail.com>
Subject: Re: DRM pull for v5.3-rc1
To:     Jason Gunthorpe <jgg@mellanox.com>
Cc:     Dave Airlie <airlied@gmail.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Jerome Glisse <jglisse@redhat.com>,
        Thomas Hellstrom <thellstrom@vmware.com>,
        Stephen Rothwell <sfr@canb.auug.org.au>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jul 15, 2019 at 5:04 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote:
>
> > > Linus, do you have any advice on how best to handle sharing mm
> > > patches? The hmm.git was mildly painful as it sits between quilt on
> > > the -mm side and what seems like 'a world of interesting git things'
> > > on the DRM side (but maybe I just don't know enough about DRM).
> >
> > I think the approach in this merge window worked fairly well:
> > - refactor/rework core mm stuff in (h)mm.git
> > - handle all the gpu stuff in drm.git
> > - make the clashes workable through some clever prep patches like
> >   we've done this time around
>
> Okay, as long as we agree.
>
> I think part of the challenge with hmm.git was setting some
> expectation for managing conflicts - there is some happy middle ground
> between none & scary we need to navigate to make this work.
>
> > I think Linus wants to be able to look through core mm stuff quite
> > closely, so not a good idea if we deeply intertwin it with one of the
> > biggest subsystems there is.
>
> There is definately a bunch of stuff that is under the mm/ directory
> but is not quite 'core mm' - it would be good if we could rely on
> mailing list review of that part and use a topic workflow to manage
> things. This was/is more or less my plan with hmm.git
>
> Otherwise yes, as much as reasonable we should avoid topic merges
> between the trees.
>
> However, I again see conflict risk coming this cycle ..
>
> >  And I don't think there will be a real conflict like this every
> > merge window, this should be the exception.  Worst case we have to
> > stage some work 1 release cycle apart, i.e.  merge mm stuff first,
> > then drm 3 months later.
>
> I really dislike this idea. Not being able to provide users for core
> APIs is a huge process/review problem. Worse it tends to create a
> 'ladder' where in-flight changes to drivers (to implement the new
> core) now block any changes to the core APIs on alternating cycles. So
> 'the big pitcture' starts to fall a part if we can't co-ordinate cross
> tree changes in some way.
>
> .. and honestly, splitting a review process across a 9 week gap is one
> of the best ways I've seen to get a poor quality review :(
>
> I'm pretty familiar with this problem, we had it in spades between RDMA
> and netdev for a long time, and it is finally fully resolved now
> through a careful use of topic branches and merges.
>
> For example, next week I'll queue CH's patches that shift the last
> batch of hmm 'conflict management' shims into nouveau, and tries to
> fix them:
>
>   https://patchwork.kernel.org/project/linux-mm/list/?series=141835
>
> This is something uncontroversial that really should go into the DRM
> world as a topic so it doesn't interfere with ongoing nouveau dev. But
> I want to keep the hmm.c/.h bits in the hmm.git to avoid conflicts.
>
> So, I'll put it on a topic and send you two a note next week to decide
> if you want to merge it or not. I'm really unclear how nouveau's and
> AMD's patchflow works..

DRM is 2-level for pretty much everything. First it lands in a driver
tree (or a collectiv of drivers, like in drm-misc). Then those send
pull requests to drm.git for integration. Busy trees do that every 1-2
weeks (e.g. amdgpu), slower trees once per merge window (e.g. nouveau)
for drm-next, similar for drm-fixes.
-Daniel


--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch