Date:   Wed, 1 Feb 2017 14:03:32 -0500
From:   Sean Paul <seanpaul@...omium.org>
To:     Emil Velikov <emil.l.velikov@...il.com>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        devicetree <devicetree@...r.kernel.org>,
        "moderated list:ARM/S5P EXYNOS AR..." 
        <linux-samsung-soc@...r.kernel.org>, cw00.choi@...sung.com,
        Donghwa Lee <dh09.lee@...sung.com>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        andi.shyti@...sung.com, jh80.chung@...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 Wed, Feb 01, 2017 at 03:29:40PM +0000, Emil Velikov wrote:
> 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.
> 

Seems like I kicked up some dust here, for that I apologize. I certainly did not
intend to diminish Thierry's (or anyone else's) role as maintainer.

To put this as concisely as I can, I thought drm_panel would be a good candidate
for -misc given:
        - drm_bridge is already maintained there
        - the drivers are small, and we just resolved to maintain small drivers
          in -misc
        - new patches are blocked on a single reviewer/committer as opposed to a
          qualified committee (which I have come to understand is a feature in
          this instance)

So if we can't migrate it to -misc now, for fear of quality issues, what are the
steps necessary to "de-stage" it?

Sean


> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Powered by blists - more mailing lists