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.
Attachment:
signature.asc
Description: PGP signature
