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> <CAHk-=wgEimwxXiDUdp9eSGZn4j6n8g-4KhdEG0kPVgKFQeAXgw@mail.gmail.com>
In-Reply-To: <CAHk-=wgEimwxXiDUdp9eSGZn4j6n8g-4KhdEG0kPVgKFQeAXgw@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 15 Jul 2019 12:00:28 -0700
Message-ID: <CAHk-=wjZ6kGFJyfXEeOzmw_eZDqvcaZ=FnFpR_c3eUmPS5M5EQ@mail.gmail.com>
Subject: Re: DRM pull for v5.3-rc1
To:     Jason Gunthorpe <jgg@mellanox.com>
Cc:     Dave Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        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 11:16 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe <jgg@mellanox.com> wrote:
> >
> > The 'hmm' tree is something I ran to try and help workflow issues like
> > this, as it could be merged to DRM as a topic branch - maybe consider
> > this flow in future?
> >
> > Linus, do you have any advice on how best to handle sharing mm
> > patches?
>
> I don't have a lot of advice except for "very very carefully".
>
> I think the hmm tree worked really well this merge window, at least
> from my standpoint.

Side note: I suspect that having a separate branch maintained by a
separate person actually does help the "very carefully" part.

I think the hmm branch ended up getting more "incidental review"
simply because of how it was done. So even if the original reason for
the separate branch was to resolve some quilt/git integration issues,
I would not be at all surprised if just the extra indirection through
another person ended up making both the sending and receiving side
think more about each patch and think more about the abstraction.

The hmm branch didn't actually seem to have any of the core VM people
reviewing it either, but it did have reviewers across companies for
all the patches, and I do think that that makes a difference.

It's _soo_ easy for a patch series to be developed inside one company
by a couple of people who are probably in the same group, and have the
exact same objectives, to be a lot more biased (and likely biased not
towards the mm goals, but the goals of the code _outside_ the mm).

This is just a long-winded way to say "I do think that the separate
and external branch with multiple interested parties" can have some
inherent advantages, when you actually have multiple people looking at
it with care and intent.

(And here the fact that you have multiple subsystems looking at the
code is very much part of what makes it a good model - if it was just
an external branch for one single user - the vmware gfx driver - you
wouldn't get the same kind of advantages. So it's not the "external
branch" part itself, it's the "multiple users who care" part that
likely causes people to think more about the end result)

Again - maybe I'm rationalizing, and the hmm branch just randomly
happened to work well this time. I do like having multiple people from
different groups look at things, though.

                    Linus