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

Sumit Semwal sumit.semwal at linaro.org
Fri Jun 26 04:43:53 UTC 2020


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


More information about the Intel-gfx mailing list