[PATCH v14 0/5] DMA-BUF Heaps (destaging ION)

[John Stultz]

On Mon, Nov 4, 2019 at 12:18 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri,  1 Nov 2019 21:42:33 +0000
> John Stultz <john.stultz at linaro.org> wrote:
>
> > This again? I know!
> >
> > Apologies to all who hoped I'd stop bothering them with this
> > patch set, but I ran afoul of the DRM tree rules by not
> > getting the userland patches properly reviewed prior to the
> > patches landing (I mistakenly was waiting for the patches to
> > land upstream before pushing the userland patches). Thus,
> > these were correctly reverted from the drm-misc-next tree.
>
> Hi John,
>
> mind, you have to get userland patches reviewed and accepted but *not
> pushed*.
>
> You cannot push/merge userland patches before the kernel patches have
> properly landed, that bit you got right. But the supposedly confusing
> bit is that for kernel patches to land, the userspace patches must be
> reviewed and accepted first.
>
> I just wanted to clarify this since you wrote "before pushing the
> userland patches" above.

Yea. Sorry, "pushed" isn't a very clear term. In AOSP, one must push a
patch to Gerrit before it is reviewed.
However, once something is reviewed it usually is merged immediately
(pending automated precommit testing).

So I tend to use the term "pushed for review" as submitting patches
for review as ready to be merged. In this case, technically I had
actually "pushed" the changes to Gerrit, but hadn't added anyone to
review, to ensure the patches were not' accidentally reviewed and
merged.
But If you look at the Gerrit log now, you'll see I've added reviewers
and provided a note explicitly to not merge the changes.

So apologies for the confusion. I do believe I understand the
requirement now, and am doing my best to adhere to them.

That said, given different userland projects use different approaches,
I do find it a little strange on the insistence that userland patches
cannot be merged to their project before the kernel changes land.
Obviously no interface is final and any userland that does so has some
risk that it will change and break, but there are many cases where
distros support new features in their userland not yet merged
upstream.  Ensuring there is a real opensource user for the kernel
feature is important, but I'm not sure I understand why the kernel is
dictating rules as to how userspace merges code.

thanks
-john