Quick clarification. On Wed, May 24, 2017 at 9:52 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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). 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
