Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

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 <thierry.reding@xxxxxxxxx> wrote:
>>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>>> Thierry Reding <thierry.reding@xxxxxxxxx> writes:
>>>>
>>>>> [ Unknown signature status ]
>>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>>> Thierry Reding <thierry.reding@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>