From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752549AbdBCEqX (ORCPT ); Thu, 2 Feb 2017 23:46:23 -0500 Received: from mailout3.samsung.com ([203.254.224.33]:52130 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752317AbdBCEqU (ORCPT ); Thu, 2 Feb 2017 23:46:20 -0500 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: b6c32a39-f79c86d000001a4c-f1-58940b182c55 Content-transfer-encoding: 8BIT Message-id: <58940B18.9090603@samsung.com> Date: Fri, 03 Feb 2017 13:46:16 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Emil Velikov , Thierry Reding Cc: Eric Anholt , devicetree , "moderated list:ARM/S5P EXYNOS AR..." , Donghwa Lee , "Linux-Kernel@Vger. Kernel. Org" , andi.shyti@samsung.com, jh80.chung@samsung.com, cw00.choi@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: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCJsWRmVeSWpSXmKPExsWy7bCmnq4E95QIg0nHDS22H3nGanH9y3NW i/lHzgFZ5+0srnx9z2ax5+o9JosDjZcZLd4v72KzWDqjj9Xixq82Vov+x6+ZLc6f38BucXnX HDaLGef3MVn83DWPxYHfo+n9MTaPnbPusntsWtXJ5nG/+ziTR9+WVYwenzfJBbBFpdpkpCam pBYppOYl56dk5qXbKnkHxzvHm5oZGOoaWlqYKynkJeam2iq5+AToumXmAJ2spFCWmFMKFApI LC5W0rezKcovLUlVyMgvLrFVijY0NNIzNDDXMzIy0jMxjrUyMgUqSUjNaDjWwljwXq3ixaJl zA2M++S7GDk5JARMJLr/f2eDsMUkLtxbD2RzcQgJ7GCUOHtsDxOE084kseXYERaYjuVnHrFC JOYwSpx7+pkZJMErICjxY/I9oCIODmYBeYkjl7JBwswCmhIvvkxigai/xyjR0trJAlGvJXFk 5TpWEJtFQFVi8vJ5TCA2G5A9ccV9sJNEBSIkds7/xg5ii4DYE7rABjELzGCR6JrxDqxZWCBK YvLCb2A2p0CwxLOPJ8CukxB4yS4xccEKZpCLJARkJTYdgDJdJL5slYN4Rlji1fEt7BC2tMSq f7eYIFq7GSWu9/SwQTgdjBJ/O/9DvW8scf/BPWaI1/gk3n3tYYUYyivR0SYEUeIh8WvGDUYI 21Hiy94WdojvD7NIrPy6h30Co/wspACbhQiwWUgBtoCReRWjWGpBcW56arFhgalecWJucWle ul5yfu4mRnCK1bLcwXjsnM8hRgEORiUe3hPekyOEWBPLiitzDzFKcDArifCy/gMK8aYkVlal FuXHF5XmpBYfYjQFhvdEZinR5Hxg+s8riTc0MTM0MTIxNDQ3MjBSEudlNZgYISSQnliSmp2a WpBaBNPHxMEp1cC4y2bKFr+7n+3dGeLNmKIyk/IuePa8PBj5K0Z5/vML/yXmFWWu2pBoWsdx 8nTuSq4zH1by6XhrTfSfPktUa2m93TnVl5qL2ZkvL1TeN8fNdd7L87sqtx6OCtpQweb5y97z +lGr7tfnLxopJZ1sD5yyNuq549JVleknNaq8pO8aW6/qnaWnqMKsxFKckWioxVxUnAgA88ms zccDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsVy+t9jQV0J7ikRBheeSltsP/KM1eL6l+es FvOPnAOyzttZXPn6ns1iz9V7TBYHGi8zWrxf3sVmsXRGH6vFjV9trBb9j18zW5w/v4Hd4vKu OWwWM87vY7L4uWseiwO/R9P7Y2weO2fdZffYtKqTzeN+93Emj74tqxg9Pm+SC2CLcrPJSE1M SS1SSM1Lzk/JzEu3VQoNcdO1UFLIS8xNtVWK0PUNCVJSKEvMKQXyjAzQgINzgHuwkr5dgltG w7EWxoL3ahUvFi1jbmDcJ9/FyMkhIWAisfzMI1YIW0ziwr31bF2MXBxCArMYJbZ8fsMIkuAV EJT4MfkeSxcjBwezgLzEkUvZEKa6xJQpuRDlDxglZh5fA1WuJXFk5TqwmSwCqhKTl89jArHZ gOyJK+6zgfSKCkRIdJ+oBAmLAJkb7+1nApnDLDCDRWLSwx/MIAlhgSiJc9PfskIsOMoi0Xf9 MAtIglMgWGLqsnnsExiBrkQ4bxbCebMQzlvAyLyKUSK1ILmgOCk91zAvtVyvODG3uDQvXS85 P3cTIzhun0ntYDy4y/0QowAHoxIP74YzkyOEWBPLiitzDzFKcDArifCy/gMK8aYkVlalFuXH F5XmpBYfYjQF+m8is5Rocj4wpeSVxBuamJuYGxtYmFtamhgpifM2zn4WLiSQnliSmp2aWpBa BNPHxMEp1cB4PFJb1oBnR8WaMG5fTduf7VNPeqtvTXx9csa+2zx3+/d9Ma3Pn6li11ezeufi 85c+fm3PCdAWDZBa9uBPSFz26nTJHy+D962OsbrZLyEYfFi+c9PRrkSVN3J1pVzr71U/akqJ DWO8vJrpVzZTu8KEw6knNaYJbtXr9ur79l1r72TGjV0PDv1QYinOSDTUYi4qTgQAyvhHyfEC AAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170203044616epcas1p33f29ada07e7f9130f8e73e78915306a1 X-Msg-Generator: CA X-Sender-IP: 203.254.230.26 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: 101P DLP-Filter: Pass X-CFilter-Loop: Reflected X-HopCount: 7 X-CMS-RootMailID: 20170111063408epcas5p2e6ec091549c3ffed8462fd95d11d3c82 X-RootMTR: 20170111063408epcas5p2e6ec091549c3ffed8462fd95d11d3c82 References: <1484116439-7275-3-git-send-email-hoegeun.kwon@samsung.com> <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> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글: > 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. > > 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. It's true and totally agree. I can really understand Thierry but I think we need to think about maintainer's role for our community. And also I think the big and small collisions between maintainers and contributors are just the process of getting better. Thanks, Inki Dae > > Thanks > Emil > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >