[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86b9ef2e-99f7-ad8c-dbfc-418c1538a0a8@redhat.com>
Date: Fri, 15 Mar 2019 15:44:57 -0700
From: Laura Abbott <labbott@...hat.com>
To: John Stultz <john.stultz@...aro.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
"Andrew F. Davis" <afd@...com>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Greg KH <gregkh@...uxfoundation.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
Liam Mark <lmark@...eaurora.org>,
Brian Starkey <Brian.Starkey@....com>,
Chenbo Feng <fengc@...gle.com>,
Alistair Strachan <astrachan@...gle.com>,
dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On 3/15/19 2:29 PM, John Stultz wrote:
> On Fri, Mar 15, 2019 at 1:18 PM Laura Abbott <labbott@...hat.com> wrote:
>>
>> On 3/5/19 12:54 PM, John Stultz wrote:
>>> +DMA-BUF HEAPS FRAMEWORK
>>> +M: Laura Abbott<labbott@...hat.com>
>>> +R: Liam Mark<lmark@...eaurora.org>
>>> +R: Brian Starkey<Brian.Starkey@....com>
>>> +R: "Andrew F. Davis"<afd@...com>
>>> +R: John Stultz<john.stultz@...aro.org>
>>> +S: Maintained
>>> +L: linux-media@...r.kernel.org
>>> +L: dri-devel@...ts.freedesktop.org
>>> +L: linaro-mm-sig@...ts.linaro.org (moderated for non-subscribers)
>>> +F: include/uapi/linux/dma-heap.h
>>> +F: include/linux/dma-heap.h
>>> +F: drivers/dma-buf/dma-heap.c
>>> +F: drivers/dma-buf/heaps/*
>>> +T: git git://anongit.freedesktop.org/drm/drm-misc
>>
>> So I talked about this with Sumit privately but I think
>> it might make sense to have me step down as maintainer when
>> this goes out of staging. I mostly worked on Ion at my
>> previous position and anything I do now is mostly a side
>> project. I still want to see it succeed which is why I
>> took on the maintainer role but I don't want to become blocking
>> for people who have a stronger vision about where this needs
>> to go (see also, I'm not working with this on a daily basis).
>>
>> If you just want someone to help review or take patches
>> to be pulled, I'm happy to do so but I'd hate to become
>> the bottleneck on getting things done for people who
>> are attempting to do real work.
>
> I worry this will make everyone to touch the side of their nose and
> yell "NOT IT!" :)
>
> First of all, thank you so much for your efforts maintaining ION along
> with your attempts to drag out requirements from interested parties
> and the numerous attempts to get collaborative discussion going at
> countless conferences! Your persistence and continual nudging in the
> face of apathetic private users of the code probably cannot be
> appreciated enough!
>
> Your past practical experience with ION and active work with the
> upstream community made you a stand out pick for this, but I
> understand not wanting to be eternally stuck with a maintainership if
> your not active in the area. I'm happy to volunteer as a neutral
> party, but I worry my limited experience with some of the more
> complicated usage would make my opinions less informed then they
> probably need to be. Further, as a neutral party, Sumit would
> probably be a better pick since he's already maintaining the dmabuf
> core.
>
Honestly if you're doing the work to re-write everything, I
think you're more than qualified to be the maintainer. I
would also support Sumit as well.
> So I'd nominate Andrew, Liam or Benjamin (or all three?) as they all
> have more practical experience enabling past ION heaps on real devices
> and have demonstrated active interest in working in the community.
>
I do think this would benefit both from multiple maintainers and
from maintainers who are actively using the framework. Like I
said, I can still be a maintainer but I think having some comaintainers
would be very helpful (and I'd support any of the names you've
suggested)
> So, in other words... NOT IT! :)
I think you have to shout "Noes goes" first. :)
> -john
>
Thanks,
Laura
P.S. For the benefit of anyone who's confused,
https://en.wikipedia.org/wiki/Nose_goes
Powered by blists - more mailing lists