Messages in this thread | | | From | Sumit Semwal <> | Date | Mon, 18 Mar 2019 10:11:18 +0530 | Subject | Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework |
| |
On Sat, 16 Mar 2019 at 04:15, Laura Abbott <labbott@redhat.com> wrote: > > On 3/15/19 2:29 PM, John Stultz wrote: > > On Fri, Mar 15, 2019 at 1:18 PM Laura Abbott <labbott@redhat.com> wrote: > >> > >> On 3/5/19 12:54 PM, John Stultz wrote: > >>> +DMA-BUF HEAPS FRAMEWORK > >>> +M: Laura Abbott<labbott@redhat.com> > >>> +R: Liam Mark<lmark@codeaurora.org> > >>> +R: Brian Starkey<Brian.Starkey@arm.com> > >>> +R: "Andrew F. Davis"<afd@ti.com> > >>> +R: John Stultz<john.stultz@linaro.org> > >>> +S: Maintained > >>> +L: linux-media@vger.kernel.org > >>> +L: dri-devel@lists.freedesktop.org > >>> +L: linaro-mm-sig@lists.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! I totally second John here - the persistence has been inspiring to me personally as well :)
> > > > 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) If it's required, I am happy to co-maintain - we could even follow the drm-misc model of multiple co-maintainers. I will support any or all of the names above as well :)
> > > 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
Best, Sumit.
| |