2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글: > On 1 February 2017 at 14:52, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: >> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: >>> Thierry Reding <thierry.reding@xxxxxxxxx> writes: >>> >>>> [ Unknown signature status ] >>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: >>>>> Thierry Reding <thierry.reding@xxxxxxxxx> writes: >>>>> >>>>>> [ Unknown signature status ] >>>>>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote: >>>>>>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote: >>>>>>>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: >>>>>>>>>> Dear Thierry, >>>>>>>>>> >>>>>>>>>> Could you please review this patch? >>>>>>>>> >>>>>>>>> Thierry, I think this patch has been reviewed enough but no comment >>>>>>>>> from you. Seems you are busy. I will pick up this. >>>>>>>> >>>>>>>> Sorry, but that's not how it works. This patch has gone through 8 >>>>>>>> revisions within 4 weeks, and I tend to ignore patches like that until >>>>>>>> the dust settles. >>>>>>>> >>>>>>> >>>>>>> Seems like the dust was pretty settled. It was posted on 1/11, pinged on 1/24, >>>>>>> and picked up on 1/31. I don't think it's unreasonable to take it through >>>>>>> another tree after that. >>>>>>> >>>>>>> I wonder if drm_panel would benefit from the -misc group maintainership model >>>>>>> as drm_bridge does. By spreading out the workload, the high-maintenance >>>>>>> patches would hopefully find someone to shepherd them through. >>>>>> >>>>>> Except that nobody except me really cares. If we let people take patches >>>>>> through separate trees or group-maintained trees they'll likely go in >>>>>> without too much thought. DRM panel is somewhat different from core DRM >>>>>> in this regard because its infrastructure is minimal and there's little >>>>>> outside the panel-simple driver. So we're still at a stage where we need >>>>>> to fine-tune what drivers should look like and how we can improve. >>>>> >>>>> I would love to care and participate in review, but with the structure >>>>> of your tree you're the only one whose review counts, so I don't >>>>> participate. >>>> >>>> Really? What exactly do you think is special about the structure of my >>>> tree? I require patches to be on dri-devel (I pick them up from the >>>> patchwork instance at freedesktop.org), the tree is publicly available >>>> and reviewed-by tags get picked up automatically by patchwork. >>>> >>>> The panel tree works exactly like any other maintainer tree. And my >>>> review is *not* the only one that counts. I appreciate every Reviewed-by >>>> tag I see on panel patches because it means that I don't have to look as >>>> closely as I have to otherwise. >>>> >>>> It is true that I am responsible for those patches, that's why I get to >>>> have the final word on whether or not a patch gets applied. And that's >>>> no different from any other maintainer tree either. >>> >>> If me reviewing a patch isn't part of unblocking that patch getting in, >>> then I won't bother because all I could end up doing is punishing the >>> developer of the patch. Contributors have a hard enough time already. >> >> Maybe you should go and read my previous reply again more carefully. >> Perhaps then you'll realize that reviews are in fact helping in getting >> patches merged. >> >> Interestingly my inbox doesn't show you ever bothering to review panel >> patches, so maybe you should be more careful about your assumptions. >> > Gents, it's understandable that emotions might be running high. > > What's the point in pointing fingers at each other - there is enough > to go in each direction. > Let us all step back for a second and consider how we can make things better. > > I think it'll be nice to have some/most of the common concerns that > Thierry/others comes across documented - in-kernel, blog post, other. > Such that one can reference to specific points as patch falls sub-par. > We all want to have a balance of nicely written driver and quick > merge. > > Inki, I believe myself and others have invited you before on > #dri-devel. This is another medium where you can poke devs and from my > experience - it tends to be more efficient, most of the time. It's true and totally agree. I can really understand Thierry but I think we need to think about maintainer's role for our community. And also I think the big and small collisions between maintainers and contributors are just the process of getting better. Thanks, Inki Dae > > Thanks > Emil > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html