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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
