[Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"

[Christian König]

Am 26.06.20 um 06:43 schrieb Sumit Semwal:
> On Fri, 26 Jun 2020 at 01:24, Daniel Vetter <daniel at ffwll.ch> wrote:
>> Ignoring everything else ...
>>
>> On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula <jani.nikula at linux.intel.com> wrote:
>>> As a side note, there seem to be extra checks in place for acks when
>>> applying non-i915 patches to drm-intel; there are no such checks for
>>> drm-misc.
>> One option to generalize that that I pondered is to consult
>> get_maintainers.pl asking for git repo link, and if that returns
>> something else, then insist that there's an ack from a relevant
>> maintainer. It's a bit of typing, but I think the bigger problem is
>> that there's a ton of false positives.
> Right; for the particular patch, I wasn't even in the to: or cc: field
> and that made it slip from my radar. I would definitely ask any one
> sending patches for dma-buf directory to follow the get_maintainers.pl
> religiously.
>> But maybe that's a good thing, would give some motivation to keep
>> MAINTAINERS updated.

Should I maybe add myself as maintainer as well? I've written enough 
stuff in there to know the code quite a bit.

Christian.

>>
>> The other issue is though that drm-misc is plenty used to merge
>> patches even when the respective maintainers are absent for weeks, or
>> unresponsive. If we just blindly implement that rule, then the only
>> possible Ack for these would be Dave&me as subsystem maintainers, and
>> I don't want to be in the business of stamping approvals for all this
>> stuff. Much better if people just collaborate.
>>
>> So I think an ack check would be nice, but probably not practical.
>>
>> Plus in this situation here drm-misc.git actually is the main repo,
>> and we wont ever be able to teach a script to make a judgement call of
>> whether that patch has the right amount of review on it.
>> -Daniel
> Best,
> Sumit.