Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1570199 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <inki.dae@samsung.com> - 2017-01-31 01:10 +0100
    Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-01-31 10:00 +0100
      Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <inki.dae@samsung.com> - 2017-01-31 10:30 +0100
      Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Andrzej Hajda <a.hajda@samsung.com> - 2017-01-31 13:10 +0100
        Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-02-02 19:00 +0100
          Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Andrzej Hajda <a.hajda@samsung.com> - 2017-02-03 10:00 +0100
            Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Daniel Vetter <daniel@ffwll.ch> - 2017-02-03 10:00 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Andrzej Hajda <a.hajda@samsung.com> - 2017-02-06 10:20 +0100
                Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Daniel Vetter <daniel@ffwll.ch> - 2017-02-06 10:50 +0100
            Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-02-06 11:40 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Andrzej Hajda <a.hajda@samsung.com> - 2017-02-07 11:00 +0100
      Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Sean Paul <seanpaul@chromium.org> - 2017-01-31 15:50 +0100
        Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-01-31 16:10 +0100
          Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Sean Paul <seanpaul@chromium.org> - 2017-01-31 17:00 +0100
            Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-01-31 22:30 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Emil Velikov <emil.l.velikov@gmail.com> - 2017-01-31 22:50 +0100
          Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board Eric Anholt <eric@anholt.net> - 2017-01-31 19:30 +0100
            Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-01-31 22:40 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board Eric Anholt <eric@anholt.net> - 2017-02-01 00:00 +0100
                Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-02-01 16:00 +0100
                  Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Emil Velikov <emil.l.velikov@gmail.com> - 2017-02-01 16:30 +0100
                    Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Sean Paul <seanpaul@chromium.org> - 2017-02-01 20:10 +0100
                      Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <inki.dae@samsung.com> - 2017-02-03 06:50 +0100
                    Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <inki.dae@samsung.com> - 2017-02-03 05:50 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <inki.dae@samsung.com> - 2017-02-01 01:00 +0100
                Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-02-01 15:50 +0100
                  Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <inki.dae@samsung.com> - 2017-02-02 13:50 +0100
                    Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-02-02 21:00 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board Jani Nikula <jani.nikula@linux.intel.com> - 2017-02-02 16:40 +0100
                Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-02-02 17:50 +0100
            Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Thierry Reding <thierry.reding@gmail.com> - 2017-01-31 23:00 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver  on TM2 board Daniel Vetter <daniel@ffwll.ch> - 2017-02-02 15:30 +0100
    Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Krzysztof Kozlowski <krzk@kernel.org> - 2017-01-31 10:30 +0100
      Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <inki.dae@samsung.com> - 2017-01-31 10:40 +0100
        Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Krzysztof Kozlowski <krzk@kernel.org> - 2017-01-31 11:10 +0100
          Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <daeinki@gmail.com> - 2017-01-31 11:50 +0100
            Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Krzysztof Kozlowski <krzk@kernel.org> - 2017-01-31 12:40 +0100
              Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Inki Dae <daeinki@gmail.com> - 2017-01-31 14:10 +0100
      Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on  TM2 board Hoegeun Kwon <hoegeun.kwon@samsung.com> - 2017-02-01 06:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1571664

On 1 February 2017 at 14:52, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>> Thierry Reding <thierry.reding@gmail.com> writes:
>>
>> > [ Unknown signature status ]
>> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>> >> Thierry Reding <thierry.reding@gmail.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.

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#1572901

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@gmail.com> wrote:
>>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>>> Thierry Reding <thierry.reding@gmail.com> writes:
>>>>
>>>>> [ Unknown signature status ]
>>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>>> Thierry Reding <thierry.reding@gmail.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)

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
> 

[toc] | [prev] | [next] | [standalone]

#1572884

2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글:
> On 1 February 2017 at 14:52, Thierry Reding <thierry.reding@gmail.com> wrote:
>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>>> Thierry Reding <thierry.reding@gmail.com> writes:
>>>
>>>> [ Unknown signature status ]
>>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>>> Thierry Reding <thierry.reding@gmail.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.
> 
> 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
> 
> 

[toc] | [prev] | [next] | [standalone]

#1571214

2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>> Thierry Reding <thierry.reding@gmail.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.

I don't think the panel tree works exactly like other maintainer tree.

I'd like to recommend you to read below Greg's blog. This blog says about *Role of a Linux Kernel Maintainer*.
http://www.kroah.com/log/linux/maintainer_pledge.html

Especially, I'd like to emphasize below things,
- I will review your patch within 1-2 weeks.
- I will offer semi-constructive criticism of your patches.
- I will let you know the status of your patch if it is rejected, or if it is accepted, what tree it has gone into, where you can find it, and when you can expect to see it merged into Linus's tree.

Why do you ignore contributor's patch? Even though the patch is ugly, I think you need to point it out and give your feedback to contributers as a maintainer.
There was some cases I often missed to review with busy work but I don't ignore contributor's patch.
That was why I tried to pick this patch up to my tree to induce your feedback.

You mentioned like below,
"This patch has gone through 8 revisions within 4 weeks, and I tend to ignore patches like that until the dust settles."

Yes, it's been over a month since contributor sent this patch, and even he requested ping~~~ but there was no comment from you.
You say "I tend to ignore patches like that until the dust settles."

I'd like to say *maintainer is really not a place for power*, and maintainer would implicitly have a role to encourage in contribution activity of contributer.

And you are continuing reply to other maintainer's comments but no comment to the contributor. This guy would still be ping~. :)
You said you've repeatedly complained but how new contributors know this?

And you also said,
"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"

Please, move panel directory to drivers/staging so that other contributors aren't confused. I think drm-panel should be stayed in staging yet until the things you mentioned will be improved because while being discussed and improved, other contributors will continue their contributions.

Thanks,
Inki Dae

> 
> 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.
> 
>> As is, I'm stuck out here with my panel driver I submitted on December
>> 14th completely ignored, and no other developer will look at it because
>> their review doesn't count and only yours does.
> 
> That's the same lame excuse as above. Nobody's keeping you or anyone
> else from reviewing panel patches.
> 
> The truth is that reviewing code is hard and time-consuming, and that's
> why nobody can be bothered to do it. That has nothing whatsoever to do
> with how any specific maintainer operates.
> 
>> I would love for drm-panel to be moved under -misc.
> 
> Like that's going to magically motivate people to spend their time
> reviewing other patches. The only thing that group maintainership adds
> is redundancy.
> 
> Thierry
> 

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote:
> 
> 
> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
> >> Thierry Reding <thierry.reding@gmail.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.
> 
> I don't think the panel tree works exactly like other maintainer tree.
> 
> I'd like to recommend you to read below Greg's blog. This blog says
> about *Role of a Linux Kernel Maintainer*.
> http://www.kroah.com/log/linux/maintainer_pledge.html

Okay, now you're being unfair. You can't compare people to Greg. He
is beyond human.

> Especially, I'd like to emphasize below things,
> - I will review your patch within 1-2 weeks.
> - I will offer semi-constructive criticism of your patches.
> - I will let you know the status of your patch if it is rejected, or
> if it is accepted, what tree it has gone into, where you can find it,
> and when you can expect to see it merged into Linus's tree.

First, this is a pledge by Greg, and you can hardly hold me to this if
it isn't coming from me. I agree that the above is ideal, but I'm also
much less efficient as a maintainer as Greg. So are many others. There
simply isn't enough bandwidth to be able to do the above in every case
in addition to the day job and real life.

That said, when I do get around to review patches I think I'm pretty
good at the second and third points, though.

Secondly, it's very convenient how you focus on the maintainers' duties
and completely leave out what maintainers expect from contributors. If
you go and read some of the references linked to by Greg's post, maybe
you'll understand my position a little better as well.

> Why do you ignore contributor's patch? Even though the patch is ugly,
> I think you need to point it out and give your feedback to
> contributers as a maintainer.
> There was some cases I often missed to review with busy work but I
> don't ignore contributor's patch.

I will admit that ignoring the patch in this instance may not have been
the best course of action. But this particular instance was making it
exceptionally difficult for me, which is why I was going to shunt this
until the next cycle so that I could focus on getting the less tiresome
patches in.

And interestingly nobody seems to care about this current discussion
either. So yesterday somebody requested another change to the DT binding
after this discussion had started, and after I had NAK'ed the patch, but
then I see that today there's yet another revision with no attempt to do
anything about the concerns that I had raised.

> That was why I tried to pick this patch up to my tree to induce your
> feedback.
> 
> You mentioned like below,
> "This patch has gone through 8 revisions within 4 weeks, and I tend to
> ignore patches like that until the dust settles."

Yes, two or three of those weeks were during a Christmas break and while
the merge window was open. Sometimes maintainers do need time to
recharge.

> Yes, it's been over a month since contributor sent this patch, and
> even he requested ping~~~ but there was no comment from you.
> You say "I tend to ignore patches like that until the dust settles."

And I did look at the patch after seeing the ping, but I immediately got
frustrated because it repeats the same mistakes that I had been
complaining about, and evidently had been too lax about, when the other
two Samsung drivers got merged. And I do remember some of the names that
were involved previously, so I think it's fair to assume that you knew I
wasn't happy about it, and yet you keep sending the same crappy code.

> I'd like to say *maintainer is really not a place for power*, and
> maintainer would implicitly have a role to encourage in contribution
> activity of contributer.

Those are two orthogonal issues. Of course maintainership is about
power, because otherwise how is a maintainer different from a regular
contributor?

And I do encourage contributions, as long as they are worthy. I did go
through the trouble of explaining the last few times why I think these
drivers aren't good enough, but I'm not very motivated to do it once
more because I did try and be encouraging in the past, and did accept
patches because I thought somebody would eventually come around and do
things better with the next submission. But I was proven wrong. If you
don't care about addressing the issues I bring up during review, I can
not be expected to care about your patch submissions any longer.

> And you are continuing reply to other maintainer's comments but no
> comment to the contributor. This guy would still be ping~. :)

I fully expect contributors to read all of the comments that are made in
response to their submission. If they can't be bothered to follow the
discussion that ensues from their contributions, why should I bother
looking at their patches?

> You said you've repeatedly complained but how new contributors know this?
> 
> And you also said,
> "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"
> 
> Please, move panel directory to drivers/staging so that other
> contributors aren't confused. I think drm-panel should be stayed in
> staging yet until the things you mentioned will be improved because
> while being discussed and improved, other contributors will continue
> their contributions.

You're twisting my words. I'm not saying that the DRM panel framework
should be in staging. What I am saying is that we have only a handful of
drivers, and most people find that panel-simple is a suitable one. And I
think it works great for those cases.

But the other more complicated drivers are a new thing, so we don't have
anything like best practices yet. But when I look at the current patches
as well as the existing Samsung panel drivers that it no doubt was
inspired by, I realize this is not at all something I consider a good
example of how such drivers should be written. So we're going to have to
find ways to improve this before I'm going to accept this patch.

Thierry

[toc] | [prev] | [next] | [standalone]

#1572330

Dear Thierry,


2017년 02월 01일 23:44에 Thierry Reding 이(가) 쓴 글:
> On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote:
>>
>>
>> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>>>> Thierry Reding <thierry.reding@gmail.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.
>>
>> I don't think the panel tree works exactly like other maintainer tree.
>>
>> I'd like to recommend you to read below Greg's blog. This blog says
>> about *Role of a Linux Kernel Maintainer*.
>> http://www.kroah.com/log/linux/maintainer_pledge.html
> 
> Okay, now you're being unfair. You can't compare people to Greg. He
> is beyond human.
> 
>> Especially, I'd like to emphasize below things,
>> - I will review your patch within 1-2 weeks.
>> - I will offer semi-constructive criticism of your patches.
>> - I will let you know the status of your patch if it is rejected, or
>> if it is accepted, what tree it has gone into, where you can find it,
>> and when you can expect to see it merged into Linus's tree.
> 
> First, this is a pledge by Greg, and you can hardly hold me to this if
> it isn't coming from me. I agree that the above is ideal, but I'm also
> much less efficient as a maintainer as Greg. So are many others. There
> simply isn't enough bandwidth to be able to do the above in every case
> in addition to the day job and real life.
> 
> That said, when I do get around to review patches I think I'm pretty
> good at the second and third points, though.

Agree. You did well really.

> 
> Secondly, it's very convenient how you focus on the maintainers' duties
> and completely leave out what maintainers expect from contributors. If
> you go and read some of the references linked to by Greg's post, maybe
> you'll understand my position a little better as well.
> 
>> Why do you ignore contributor's patch? Even though the patch is ugly,
>> I think you need to point it out and give your feedback to
>> contributers as a maintainer.
>> There was some cases I often missed to review with busy work but I
>> don't ignore contributor's patch.
> 
> I will admit that ignoring the patch in this instance may not have been
> the best course of action. But this particular instance was making it
> exceptionally difficult for me, which is why I was going to shunt this
> until the next cycle so that I could focus on getting the less tiresome
> patches in.
> 
> And interestingly nobody seems to care about this current discussion
> either. So yesterday somebody requested another change to the DT binding
> after this discussion had started, and after I had NAK'ed the patch, but
> then I see that today there's yet another revision with no attempt to do
> anything about the concerns that I had raised.
> 
>> That was why I tried to pick this patch up to my tree to induce your
>> feedback.
>>
>> You mentioned like below,
>> "This patch has gone through 8 revisions within 4 weeks, and I tend to
>> ignore patches like that until the dust settles."
> 
> Yes, two or three of those weeks were during a Christmas break and while
> the merge window was open. Sometimes maintainers do need time to
> recharge.
> 
>> Yes, it's been over a month since contributor sent this patch, and
>> even he requested ping~~~ but there was no comment from you.
>> You say "I tend to ignore patches like that until the dust settles."
> 
> And I did look at the patch after seeing the ping, but I immediately got
> frustrated because it repeats the same mistakes that I had been
> complaining about, and evidently had been too lax about, when the other
> two Samsung drivers got merged. And I do remember some of the names that
> were involved previously, so I think it's fair to assume that you knew I
> wasn't happy about it, and yet you keep sending the same crappy code.

I think we hadn't reached any conclusion for futher specified TODO.

And below thing Andrzej H. mentioned is all which making you to complain? 
https://lkml.org/lkml/2017/1/31/353

> 
>> I'd like to say *maintainer is really not a place for power*, and
>> maintainer would implicitly have a role to encourage in contribution
>> activity of contributer.
> 
> Those are two orthogonal issues. Of course maintainership is about
> power, because otherwise how is a maintainer different from a regular
> contributor?
> 
> And I do encourage contributions, as long as they are worthy. I did go
> through the trouble of explaining the last few times why I think these
> drivers aren't good enough, but I'm not very motivated to do it once
> more because I did try and be encouraging in the past, and did accept
> patches because I thought somebody would eventually come around and do
> things better with the next submission. But I was proven wrong. If you

Please, do not expect all other contributors know and understand this. Especially, what you talked about in the past would be an unknown fact to new people.
And please, do encourage contributions from people who may post really ugly things you think. If you ignore or don't encourage them, then the community will stop growing.

Seems you want to have only the maintainer's role as a technical leader.

I think you already know below Daniel's blog,
http://blog.ffwll.ch/2017/01/maintainers-dont-scale.html

I realized other maintainers had been contemplating this - maintainer's role - for a long time.
I'd like to recommend you to read *It's About the People* chapter.

Thank someone for sharing this. :)

> don't care about addressing the issues I bring up during review, I can
> not be expected to care about your patch submissions any longer.

Again. That is what Andrzej H. mentioned?
https://lkml.org/lkml/2017/1/31/353

Or is there other thing I don't know?

> 
>> And you are continuing reply to other maintainer's comments but no
>> comment to the contributor. This guy would still be ping~. :)
> 
> I fully expect contributors to read all of the comments that are made in
> response to their submission. If they can't be bothered to follow the
> discussion that ensues from their contributions, why should I bother
> looking at their patches?
> 
>> You said you've repeatedly complained but how new contributors know this?
>>
>> And you also said,
>> "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"
>>
>> Please, move panel directory to drivers/staging so that other
>> contributors aren't confused. I think drm-panel should be stayed in
>> staging yet until the things you mentioned will be improved because
>> while being discussed and improved, other contributors will continue
>> their contributions.
> 
> You're twisting my words. I'm not saying that the DRM panel framework
> should be in staging. What I am saying is that we have only a handful of
> drivers, and most people find that panel-simple is a suitable one. And I
> think it works great for those cases.

I know this, and yes, maybe it can definitely reduce much code and it works well but I think this couldn't cover everything.
Display panel device have many functions by vendor. I.e., Color tone change, Outdoor mode, and so on.

And seems that you didn't reached the agreement enough with other people at least.

Thierry, if you continue to insist on this and block other contributions, you may become a diminisher than becoming a multiplier.

Thanks,
Inki Dae

> 
> But the other more complicated drivers are a new thing, so we don't have
> anything like best practices yet. But when I look at the current patches
> as well as the existing Samsung panel drivers that it no doubt was
> inspired by, I realize this is not at all something I consider a good
> example of how such drivers should be written. So we're going to have to
> find ways to improve this before I'm going to accept this patch.
> 
> Thierry
> 

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

I'm going to need to cool down for a bit. Let's resume this on Monday,
maybe we can get back to being constructive after the weekend.

Thierry

[toc] | [prev] | [next] | [standalone]

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

On Tue, 31 Jan 2017, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>> I would love for drm-panel to be moved under -misc.
>
> Like that's going to magically motivate people to spend their time
> reviewing other patches. The only thing that group maintainership adds
> is redundancy.

Adding redundancy is not an insignificant thing. I think it can be quite
liberating to not have everything and everybody depend on you. You can
defer to others when you're busy, tired, sick, whatever. Things still
move on.

And I don't think redundancy is the only thing that group maintainership
adds. You'll have maintainers that complement each other, with different
skill sets and abilities and experience. They don't all look at the same
things. As maintainers tend to be more senior folks, I find sharing the
load of the more mundane tasks of maintainership free up their time to
contribute more of their technical skills to the project, for example
review.

It's just my personal view on i915, but I think people take more
responsibility of their own work, instead of just sending patches and
waiting for stuff to happen, when they have commit access. But you have
to trust the people.

I didn't intend for this to become a kind of sales pitch, but I do think
drm-panel would be a good fit for drm-misc. Personally I think it's your
call, but I think you should think about it. (And that decision should,
obviously, be made calmly, independent of any particular patch series.)


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, Feb 02, 2017 at 05:30:34PM +0200, Jani Nikula wrote:
> On Tue, 31 Jan 2017, Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
> >> I would love for drm-panel to be moved under -misc.
> >
> > Like that's going to magically motivate people to spend their time
> > reviewing other patches. The only thing that group maintainership adds
> > is redundancy.
> 
> Adding redundancy is not an insignificant thing. I think it can be quite
> liberating to not have everything and everybody depend on you. You can
> defer to others when you're busy, tired, sick, whatever. Things still
> move on.

Oh, I certainly see the advantages in sharing maintainership. However, I
think it really only works well if you've got active developers working
together on the code already. Then it's very natural to let all of them
manage a tree.

But for drm-panel, I've rarely seen anyone review patches. Sometimes the
easy patches (i.e. panel-simple) get reviewed by parties that have some
interest in seeing the patches merged. However, there's usually no
review at all for the more complicated patches.

Given that, I doubt that group maintainership is going to have the
desired effect. Just because the tree is group maintained doesn't mean
that all of a sudden people are going to care about the patches. So I
suspect that even if panel drivers were managed in drm-misc, I'd still
be the only person reviewing the patches. And really, managing a tree
is peanuts compared to the amount of work it takes to properly review
code.

With group maintainership, for this type of tree in particular, I think
it's likely for the quality bar to be lowered. There aren't any best
practices yet for anything beyond panel-simple, and therefore little to
no review is likely going to make people still pick up patches. This is
quite different to the DRM/KMS core bits and drivers because there are
established best practices and people can usually spot when new code is
not living up to expectations.

> And I don't think redundancy is the only thing that group maintainership
> adds. You'll have maintainers that complement each other, with different
> skill sets and abilities and experience. They don't all look at the same
> things. As maintainers tend to be more senior folks, I find sharing the
> load of the more mundane tasks of maintainership free up their time to
> contribute more of their technical skills to the project, for example
> review.

I don't understand why group maintainership would be necessary for this.
Surely people will review code irrespective of who finally applies their
patch. If they don't in a single maintainer project, why would they
suddenly start reviewing code in group maintained projects?

> It's just my personal view on i915, but I think people take more
> responsibility of their own work, instead of just sending patches and
> waiting for stuff to happen, when they have commit access. But you have
> to trust the people.

That's not something that we're discussing here. Surely giving the world
access to the maintainer trees is not a goal that we're pursuing here.
It will still only be a handful of selected people that will have commit
access, so how's that going to change things for contributors that don't
have commit access?

The bottom line still is that we have a requirement to have patches
reviewed before they get applied. So even if everybody had commit access
we'd still need someone to review a patch before it gets applied. Like I
said, reviewing is really the difficult part of a maintainer's job.
Applying a patch is trivial, build-testing is equally trivial and so is
sending out a pull request. All of the above can be easily automated to
a point where it's completely painless.

> I didn't intend for this to become a kind of sales pitch, but I do think
> drm-panel would be a good fit for drm-misc. Personally I think it's your
> call, but I think you should think about it. (And that decision should,
> obviously, be made calmly, independent of any particular patch series.)

You know what? I completely agree with you that drm-panel would be a
good fit for drm-misc. It's effectively part of the DRM/KMS core and
used by most drivers. But it's never been treated that way. Maybe it
is because it's been maintained in a separate tree from the very
beginning, perhaps that was a mistake in the first place. Then again,
back when drm-panel was started we didn't have group maintainership,
so none of the existing trees would've been a good fit.

In the end, I keep getting back to the question that everybody except
me seems to know the answer to: why would there be a difference in how
contributors behave depending on the number of maintainers?

Thierry

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
[...]
> As is, I'm stuck out here with my panel driver I submitted on December
> 14th completely ignored, and no other developer will look at it because
> their review doesn't count and only yours does.

For the record, until earlier today when Daniel started to review your
patches, no doubt in response to this discussion, there was exactly one
response to one of your clock driver patches in the series.

So can we please stop singling out panel drivers? This is a general
problem that we've had across the kernel, or at least the ARM and
related parts of it, for as long as I can remember.

Thierry

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jan 31, 2017 at 10:51:06PM +0100, Thierry Reding wrote:
> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
> [...]
> > As is, I'm stuck out here with my panel driver I submitted on December
> > 14th completely ignored, and no other developer will look at it because
> > their review doesn't count and only yours does.
> 
> For the record, until earlier today when Daniel started to review your
> patches, no doubt in response to this discussion, there was exactly one
> response to one of your clock driver patches in the series.
> 
> So can we please stop singling out panel drivers? This is a general
> problem that we've had across the kernel, or at least the ARM and
> related parts of it, for as long as I can remember.

I only looked at that as part of the drm-misc small drivers experiment, to
help kickstart a review market. I didn't look at the panel stuff. And the
reason I looked at that right now is because right now we started this
experiment. That has nothing at all to do with what's going on with
drm-panel. If you look at drm-misc, the dsi patches for vc4 have now
landed, but the panel driver for the rpi 7" touchscreen hasn't.

And Eric had the dsi patches queued in his vc4 tree since a while, just
waiting to be sent out in a pull request. We've only gone through the fast
review+merging to drm-misc to try out the new process. So not related at
all I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1570515

On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki.dae@samsung.com> 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.
>

Comments from v8 were not resolved and I think we are waiting for v9:
https://lkml.org/lkml/2017/1/11/178

If that is not correct then please clarify.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1570522

2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki.dae@samsung.com> 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.
>>
> 
> Comments from v8 were not resolved and I think we are waiting for v9:
> https://lkml.org/lkml/2017/1/11/178
> 
> If that is not correct then please clarify.

Seems you pointed to change te-gpios bindings to optional. right?

I thought Rob left ack so it's no problem.
https://lkml.org/lkml/2017/1/13/626

Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

[toc] | [prev] | [next] | [standalone]

#1570550

On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae <inki.dae@samsung.com> wrote:
>
>
> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki.dae@samsung.com> 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.
>>>
>>
>> Comments from v8 were not resolved and I think we are waiting for v9:
>> https://lkml.org/lkml/2017/1/11/178
>>
>> If that is not correct then please clarify.
>
> Seems you pointed to change te-gpios bindings to optional. right?
>
> I thought Rob left ack so it's no problem.
> https://lkml.org/lkml/2017/1/13/626

Yes, change them to optional. I think it is a problem (regardless of
Rob's ack) because you are merging a driver requiring a property which
soon you want to remove. If you merge it (like this) removal of
te-gpios property will be breakage of ABI. This is not a serious
problem but knowing such plan of te-gpios removal upfront, it would be
wrong to commit such driver.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1570593

2017-01-31 19:01 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae <inki.dae@samsung.com> wrote:
>>
>>
>> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki.dae@samsung.com> 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.
>>>>
>>>
>>> Comments from v8 were not resolved and I think we are waiting for v9:
>>> https://lkml.org/lkml/2017/1/11/178
>>>
>>> If that is not correct then please clarify.
>>
>> Seems you pointed to change te-gpios bindings to optional. right?
>>
>> I thought Rob left ack so it's no problem.
>> https://lkml.org/lkml/2017/1/13/626
>
> Yes, change them to optional. I think it is a problem (regardless of
> Rob's ack) because you are merging a driver requiring a property which
> soon you want to remove. If you merge it (like this) removal of
> te-gpios property will be breakage of ABI. This is not a serious
> problem but knowing such plan of te-gpios removal upfront, it would be
> wrong to commit such driver.

This is a trivial thing so it doesn't make breakage of ABI because the
property, te-gpios, is *optional*.

Anyway, this wouldn't be *the things* Thierry mentioned.

Thanks,
Inki Dae

>
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1570631

On Tue, Jan 31, 2017 at 12:37 PM, Inki Dae <daeinki@gmail.com> wrote:
> 2017-01-31 19:01 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>> On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae <inki.dae@samsung.com> wrote:
>>>
>>>
>>> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>>>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki.dae@samsung.com> 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.
>>>>>
>>>>
>>>> Comments from v8 were not resolved and I think we are waiting for v9:
>>>> https://lkml.org/lkml/2017/1/11/178
>>>>
>>>> If that is not correct then please clarify.
>>>
>>> Seems you pointed to change te-gpios bindings to optional. right?
>>>
>>> I thought Rob left ack so it's no problem.
>>> https://lkml.org/lkml/2017/1/13/626
>>
>> Yes, change them to optional. I think it is a problem (regardless of
>> Rob's ack) because you are merging a driver requiring a property which
>> soon you want to remove. If you merge it (like this) removal of
>> te-gpios property will be breakage of ABI. This is not a serious
>> problem but knowing such plan of te-gpios removal upfront, it would be
>> wrong to commit such driver.
>
> This is a trivial thing so it doesn't make breakage of ABI because the
> property, te-gpios, is *optional*.

So why bindings document is not changed?

+Required properties:
(...)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+    gpio pin (active high)

Andrzej pointed this out and it is not fixed since then. What is the
problem with fixing the bindings documentation?

> Anyway, this wouldn't be *the things* Thierry mentioned.

Probably not, I did not respond to Thierry's feedback.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1570710

2017-01-31 20:30 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Tue, Jan 31, 2017 at 12:37 PM, Inki Dae <daeinki@gmail.com> wrote:
>> 2017-01-31 19:01 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>>> On Tue, Jan 31, 2017 at 11:34 AM, Inki Dae <inki.dae@samsung.com> wrote:
>>>>
>>>>
>>>> 2017년 01월 31일 18:22에 Krzysztof Kozlowski 이(가) 쓴 글:
>>>>> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki.dae@samsung.com> 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.
>>>>>>
>>>>>
>>>>> Comments from v8 were not resolved and I think we are waiting for v9:
>>>>> https://lkml.org/lkml/2017/1/11/178
>>>>>
>>>>> If that is not correct then please clarify.
>>>>
>>>> Seems you pointed to change te-gpios bindings to optional. right?
>>>>
>>>> I thought Rob left ack so it's no problem.
>>>> https://lkml.org/lkml/2017/1/13/626
>>>
>>> Yes, change them to optional. I think it is a problem (regardless of
>>> Rob's ack) because you are merging a driver requiring a property which
>>> soon you want to remove. If you merge it (like this) removal of
>>> te-gpios property will be breakage of ABI. This is not a serious
>>> problem but knowing such plan of te-gpios removal upfront, it would be
>>> wrong to commit such driver.
>>
>> This is a trivial thing so it doesn't make breakage of ABI because the
>> property, te-gpios, is *optional*.
>
> So why bindings document is not changed?

Seems Hoegeun missed this.
I also think it should specify *te-gpios is optional property* like
mipi-dsi binding document did but this doesn't breakage of ABI you
mentioned. And I'd like to say we should feel ABI breakage is a
serious problem.

Sad to say, Exynos is already broken like Marek declared. This is
really a serious problem Exynos maintainers have to fix including you
and me.

Thanks,
Inki Dae

>
> +Required properties:
> (...)
> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
> +    gpio pin (active high)
>
> Andrzej pointed this out and it is not fixed since then. What is the
> problem with fixing the bindings documentation?
>
>> Anyway, this wouldn't be *the things* Thierry mentioned.
>
> Probably not, I did not respond to Thierry's feedback.
>
> Best regards,
> Krzysztof

[toc] | [prev] | [next] | [standalone]

#1571274

On 01/31/2017 06:22 PM, Krzysztof Kozlowski wrote:
> On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae <inki.dae@samsung.com> 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.
>>
> Comments from v8 were not resolved and I think we are waiting for v9:
> https://lkml.org/lkml/2017/1/11/178
>
> If that is not correct then please clarify.

Dear Krzysztof,

I'm sorry, I was mistaken.
I will change them to optional and will send it to the V9 patch.

Best Regards,
Hoegeun

>
> Best regards,
> Krzysztof
>
>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web