On Wed, May 24, 2017 at 6:57 PM, Patrik Jakobsson <patrik.r.jakobsson@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
