From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751349AbdBATDi (ORCPT ); Wed, 1 Feb 2017 14:03:38 -0500 Received: from mail-yw0-f171.google.com ([209.85.161.171]:34876 "EHLO mail-yw0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750885AbdBATDf (ORCPT ); Wed, 1 Feb 2017 14:03:35 -0500 Date: Wed, 1 Feb 2017 14:03:32 -0500 From: Sean Paul To: Emil Velikov Cc: Thierry Reding , devicetree , "moderated list:ARM/S5P EXYNOS AR..." , cw00.choi@samsung.com, Donghwa Lee , "Linux-Kernel@Vger. Kernel. Org" , andi.shyti@samsung.com, jh80.chung@samsung.com, Kukjin Kim , ML dri-devel , Hyungwon Hwang , Krzysztof Kozlowski , Hoegeun Kwon Subject: Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board Message-ID: <20170201190331.GB14264@art_vandelay> References: <08c5d94b-c76f-af14-c08f-478e26a34a7c@samsung.com> <588FD3C3.7080508@samsung.com> <20170131085449.GA19348@ulmo.ba.sec> <20170131143853.GU20076@art_vandelay> <20170131150226.GB4519@ulmo.ba.sec> <87r33j85ap.fsf@eliezer.anholt.net> <20170131213132.GC872@mithrandir.ba.sec> <87d1f2kfgi.fsf@eliezer.anholt.net> <20170201145249.GB17698@ulmo.ba.sec> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 01, 2017 at 03:29:40PM +0000, Emil Velikov wrote: > On 1 February 2017 at 14:52, Thierry Reding wrote: > > On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: > >> Thierry Reding writes: > >> > >> > [ Unknown signature status ] > >> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: > >> >> Thierry Reding 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS