Message-id: <58940B18.9090603@samsung.com>
Date:   Fri, 03 Feb 2017 13:46:16 +0900
From:   Inki Dae <inki.dae@...sung.com>
To:     Emil Velikov <emil.l.velikov@...il.com>,
        Thierry Reding <thierry.reding@...il.com>
Cc:     Eric Anholt <eric@...olt.net>,
        devicetree <devicetree@...r.kernel.org>,
        "moderated list:ARM/S5P EXYNOS AR..." 
        <linux-samsung-soc@...r.kernel.org>,
        Donghwa Lee <dh09.lee@...sung.com>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        andi.shyti@...sung.com, jh80.chung@...sung.com,
        cw00.choi@...sung.com, Kukjin Kim <kgene@...nel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        Hyungwon Hwang <human.hwang@...sung.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Hoegeun Kwon <hoegeun.kwon@...sung.com>
Subject: Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on
 TM2 board



2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글:
> On 1 February 2017 at 14:52, Thierry Reding <thierry.reding@...il.com> wrote:
>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>> Thierry Reding <thierry.reding@...il.com> writes:
>>>
>>>> [ Unknown signature status ]
>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>> Thierry Reding <thierry.reding@...il.com> 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Powered by blists - more mailing lists