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: <CACvgo504WEd_pPrjEViH+-i8BNwEjQ-q7MdnYWJ3V6uTB_tk5Q@mail.gmail.com>
Date:   Wed, 1 Feb 2017 15:29:40 +0000
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     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

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.

Thanks
Emil