lkml.org 
[lkml]   [2017]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board


    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
    >
    >

    \
     
     \ /
      Last update: 2017-02-03 05:47    [W:7.081 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site