linux-kernel - Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87d1f2kfgi.fsf@eliezer.anholt.net>
Date:   Tue, 31 Jan 2017 14:54:53 -0800
From:   Eric Anholt <eric@...olt.net>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Sean Paul <seanpaul@...omium.org>, devicetree@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org, kgene@...nel.org,
        Donghwa Lee <dh09.lee@...sung.com>,
        linux-kernel@...r.kernel.org, andi.shyti@...sung.com,
        cw00.choi@...sung.com, jh80.chung@...sung.com,
        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

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.

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)