Maintaining small drm drivers

[Daniel Vetter]

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