Maintaining small drm drivers

[Patrik Jakobsson]

On Mon, May 29, 2017 at 9:35 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Mon, May 29, 2017 at 8:53 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>>>> Find another smaller driver in need of some cleanup (we can add more
>>>> to drm-misc), cross review. Yes it's a bit of work (see above), but at
>>>> least from the drm subsystem pov the end result will be worth it,
>>>> since more code sharing and more collaboration gives us a much
>>>> stronger community.
>>>
>>> I'm currently at a conference so I figured I'd ask around. So far,
>>> people are reluctant to get their hands dirty in a driver they've
>>> never looked at before and don't have hardware to test. From a
>>> community perspective, would you agree to require review by AMD for
>>> all Intel patches and vice versa (a slight exaggeration, I know)? I'd
>>> say that would cripple development of both drivers. There is as you
>>> say the a-b tag but I honestly doubt it's useful.
>>
>> Small driver = only 1 regular contributor. AMD and intel are anything
>> but small. And yes if I'd maintain a small driver I'd welcome to have
>> a regular exchange with other maintainers to make sure my driver is up
>> to date with drm best practices. Again gma500 is a bit special since
>> it's not moving anymore.
>
> To make it clearer what I meant to say: It's of course better if your
> reviewer has domain knowledge about your code, but if there's only 1
> regular contributor a bit of review is imo still good. As soon as
> there's a few regular contributors then a review sub-group in drm-misc
> forms (e.g. like what's happened with bridge drivers, and we
> documented that in MAINTAINERS).

Yes, a reviewer pool would be a good idea. Not just for drm-misc but
for patches on dri-devel in general. Handling of "unsorted" patches
with no direct maintainer can be improved.

Basically what I get from this is that we sacrifice some convenience
for small drivers on behalf of the bigger ones. I think that's fair
during the circumstances. Not optimal, but fair. I'll be using
drm-misc for smaller stuff and send larger series as p-r to Dave (with
r-b if I can get them). I think that makes most sense from a gma500
pov.

Cheers
Patrik

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch