Maintaining small drm drivers

[Daniel Vetter]

Quick clarification.

On Wed, May 24, 2017 at 9:52 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, May 24, 2017 at 6:57 PM, Patrik Jakobsson
> <patrik.r.jakobsson at gmail.com> wrote:
>> Hi Dave and Daniel,
>>
>> We had a little mishap this morning when I had pushed a fix for gma500
>> into drm-misc-fixes without first getting someone to review it. The
>> patch have been on the list for over a month and I don't feel like I
>> have enough karma to force someone to review it. Since I'm the only
>> one actively reviewing gma500 stuff I've effectively locked myself out
>> from submitting patches for the driver. Sure, sometimes others help
>> out and that is ofc appreciated.
>>
>> As you suggested Daniel, I could trade light-weight reviews with
>> someone else. At first it sounds reasonable but when I think about it
>> it's rather bad. Why should I sell my r-b tags cheap in order to get
>> patches into the driver I'm maintaining? This model seems broken.
>> Doing quick reviews because you trust the author is not a good idea.
>> It defeats the purpose and soils the value of your r-b tag (learned
>> from my own mistakes).

That's why we only require an acked-by tag for small drivers, it's not
a full review. So can't soil the value of your r-b tags. All the same
reasons still apply.
-Daniel

>> In the case of gma500 I'm exaggerating the problem a bit but others
>> will run into the same issue at some point. So my question is, can we
>> scrap the requirements for an r-b tag in drivers with only one
>> continuously active developer or at least make it more "soft"? Other
>> ideas are welcome.
>
> I had a really long discussion about this topic in private with
> another maintainer who expressed some unhappiness about the drm-misc
> review model. Yes it looks a bit silly that you have to trade review,
> but in the end if you think it's necessary to review other
> submissions, then imo you also need to get your own patches reviewed
> or at least sanity-checked.
>
> That's why drm-intel, drm-misc and anything else I'll ever maintain
> will have a hard&solid rule to never push my own stuff (or anyone else
> with commit rights) without review. No exceptions.
>
> In my opinion, as a maintainer of a part of the linux kernel your job
> is to be the steward of the code and contributors/community around it,
> not be the lord with special priviledges like being able to push
> unreviewed patches or nacking contributions just because you're the
> maintainer. And yes, part of the rules behind drm-misc is to make sure
> that even single-maintainer drivers do collaborate, because with most
> drivers sooner or later there will be other contributors.
>
> So at least from my side, yes there's an agenda behind this all, and
> its intentional. It also seems to work reasonable well thus far, since
> worst case drm-misc maintainers serve as reviewers of last resort.
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



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