From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752595AbdBCFsE (ORCPT ); Fri, 3 Feb 2017 00:48:04 -0500 Received: from mailout4.samsung.com ([203.254.224.34]:55615 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752230AbdBCFsB (ORCPT ); Fri, 3 Feb 2017 00:48:01 -0500 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: b6c32a59-f79be6d0000012bb-ef-5894198e5396 Content-transfer-encoding: 8BIT Message-id: <5894198D.2000307@samsung.com> Date: Fri, 03 Feb 2017 14:47:57 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Sean Paul , 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 In-reply-to: <20170201190331.GB14264@art_vandelay> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCJsWRmVeSWpSXmKPExsWy7bCmlm6f5JQIg02TJSy2H3nGanH9y3NW i/lHzgFZ5+0srnx9z2ax5+o9Jov3y7vYLJbO6GO1uPGrjdWi//FrZovz5zewW1zeNYfNYsb5 fUwWdzecZbT4uWseiwO/x+yGiyweO2fdZffYtKqTzeN+93Emj74tqxg9Pm+SC2CLSrXJSE1M SS1SSM1Lzk/JzEu3VfIOjneONzUzMNQ1tLQwV1LIS8xNtVVy8QnQdcvMATpZSaEsMacUKBSQ WFyspG9nU5RfWpKqkJFfXGKrFG1oaKRnaGCuZ2RkpGdiHGtlZApUkpCasXnGO/aCp3oVzT1n GBsYr6l2MXJwSAiYSKyZVtvFyAlkiklcuLeerYuRi0NIYCmjxN9pD5khnHYmifeL5zFDVJlI HH/VwASRmANUteM6WIJXQFDix+R7LCBTmQXkJY5cygYJMwtoSrz4MokFov4eo8SkR1sZIeq1 JGb2PQOzWQRUJSZd6GYDsdmA7Ikr7oPZogIREjvnf2MHsUUEAiQe7/gLdhGzwDIWiVdTloEV CQtESUxe+I0VxOYUMJK4/+Yy2HUSAi/ZJe7vusIG8aesxKYDUB+4SHy/c5QJwhaWeHV8CzuE LS3xd+ktRojebkaJ6z09bBBOB9Cbnf9ZIKqMJe4/uMcM8RufRO/vJ0wQC3glOtqEIEo8JNqm wILLUeLslO1Q769lkVhy7TDjBEb5WUghNgsRYrOQQmwBI/MqRrHUguLc9NRi0wJTveLE3OLS vHS95PzcTYzgFKsVuYPxysygQ4wCHIxKPLwztk+OEGJNLCuuzD3EKMHBrCTCO0N0SoQQb0pi ZVVqUX58UWlOavEhRlNggE9klhJNzgem/7ySeEMTM0MTI0sgNDc0VxLnjTKYGCEkkJ5Ykpqd mlqQWgTTx8TBKdXAKKR2uLi7WiL2+6Z5+Ye2qj5+ozO/J2z6qQOPZ+qsK5oa+uplgvDZ/23y abcPXZI5uuqKdLk3azSH7c8JLv7d84RvOAWyl/pnfFrP76R5fk2LSWqiwHvvZK3JluZhk1dp hjO3+/rNnLJjw+Iz9zSVv+feWtr1xtbm7t3Jf+7uqkpjeOGRcTrQQ4mlOCPRUIu5qDgRAFIP bXXHAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsVy+t9jQd0+ySkRBjcaGS22H3nGanH9y3NW i/lHzgFZ5+0srnx9z2ax5+o9Jov3y7vYLJbO6GO1uPGrjdWi//FrZovz5zewW1zeNYfNYsb5 fUwWdzecZbT4uWseiwO/x+yGiyweO2fdZffYtKqTzeN+93Emj74tqxg9Pm+SC2CLcrPJSE1M SS1SSM1Lzk/JzEu3VQoNcdO1UFLIS8xNtVWK0PUNCVJSKEvMKQXyjAzQgINzgHuwkr5dglvG 5hnv2Aue6lU095xhbGC8ptrFyMkhIWAicfxVAxOELSZx4d56ti5GLg4hgVmMEk3nHrKBJHgF BCV+TL7H0sXIwcEsIC9x5FI2hKkuMWVKLkT5A0aJy9P6mCHKtSRm9j1jBLFZBFQlJl3oBhvD BmRPXHGfDaRXVCBCovtEJUhYRMBP4mHPa7C1zALLWCTm7p8NNkdYIEri3PS3rBAL1rJInGi6 BzaIU8BI4v6by0wTGIGuRDhvFsJ5sxDOW8DIvIpRIrUguaA4KT3XKC+1XK84Mbe4NC9dLzk/ dxMjOG6fSe9gPLzL/RCjAAejEg9vQMXkCCHWxLLiytxDjBIczEoivDNEp0QI8aYkVlalFuXH F5XmpBYfYjQF+m8is5Rocj4wpeSVxBuamJuYGxtYmFtamhgpifM2zn4WLiSQnliSmp2aWpBa BNPHxMEp1cCYHRrIuPambO022+8z51r+UV0p3sTBtCmcQ/PZ/dM3F+wpvJK6bYrem2J218oL C2Y6yyT/1NBQyAxJu/yfqTxS+tojn+ci8uErN1dLa50oT7jgkDfZ9ti+7puBq57mC9cFx3y6 dW27klqSV9DNvEl/CmWzjuxwdVZjnNgcUdp9oC5x7aczuR+UWIozEg21mIuKEwEmEll28QIA AA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170203054758epcas5p314dcee7ae5f46358042c876a0a627a30 X-Msg-Generator: CA X-Sender-IP: 203.254.230.27 X-Local-Sender: =?UTF-8?B?64yA7J246riwG1RpemVuIFBsYXRmb3JtIExhYihTL1fshLw=?= =?UTF-8?B?7YSwKRvsgrzshLHsoITsnpAbUzUo7LGF7J6EKS/ssYXsnoQ=?= X-Global-Sender: =?UTF-8?B?SW5raSBEYWUbVGl6ZW4gUGxhdGZvcm0gTGFiLhtTYW1zdW5n?= =?UTF-8?B?IEVsZWN0cm9uaWNzG1M1L1NlbmlvciBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG1NUQUYbQzEwVjgxMTE=?= CMS-TYPE: 105P DLP-Filter: Pass X-CFilter-Loop: Reflected X-HopCount: 7 X-CMS-RootMailID: 20170201190354epcas4p13f64f3d4b4d27b10cf1222f203b25367 X-RootMTR: 20170201190354epcas4p13f64f3d4b4d27b10cf1222f203b25367 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> <20170201190331.GB14264@art_vandelay> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017년 02월 02일 04:03에 Sean Paul 이(가) 쓴 글: > 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) Agree. drm_panel is not large enough to require another maintainer. However, we had already agreed that Thierry manages drm_panel, either implicitly or explicitly. Seems he's tired now and he wants to talk about this issue again on next Monday. At the meeting, I think we could decide whether going to group maintainership model, stay as-is or other better way, including reaching consensus. Thanks, Inki Dae > > 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 >