From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60A1AAB9 for ; Thu, 27 Apr 2017 14:18:22 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C0F0CA7 for ; Thu, 27 Apr 2017 14:18:21 +0000 (UTC) Message-ID: <1493302678.2810.18.camel@HansenPartnership.com> From: James Bottomley To: Hannes Reinecke , ksummit-discuss@lists.linuxfoundation.org Date: Thu, 27 Apr 2017 10:17:58 -0400 In-Reply-To: <3caeb185-c30f-5069-8b8c-c7ccb3954175@suse.com> References: <1834084.5qZ8rLimvk@avalon> <1492631703.3217.30.camel@HansenPartnership.com> <3f55980c-1e8d-c841-2555-472ed10eb2fc@sandisk.com> <20170426084253.yvxyzb3khh2fej4j@mwanda> <1493217078.2526.8.camel@HansenPartnership.com> <1493217836.2526.10.camel@HansenPartnership.com> <87h91arzic.fsf@intel.com> <20170427104108.ppsrmuvsrofnghju@dell> <3caeb185-c30f-5069-8b8c-c7ccb3954175@suse.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Ksummit-discuss] "Maintainer summit" invitation discussion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2017-04-27 at 13:02 +0200, Hannes Reinecke wrote: > On 04/27/2017 12:41 PM, Lee Jones wrote: > > On Thu, 27 Apr 2017, Jani Nikula wrote: > > > On Wed, 26 Apr 2017, James Bottomley < > > > James.Bottomley@HansenPartnership.com> wrote: > > > > Agreed, but I think you'll find most maintainers have a "trust > > > > factor" for reviewers. Perhaps we should discuss how we arrive > > > > at this and how we should make it more public. The way I often > > > > deal with less trusted reviewers is to redo their review and > > > > point out all the things they missed and ask them not to come > > > > back until they can be more thorough. > > > > > > I think that's also a bit harsh, because I think the only way to > > > become a better reviewer is to... review. I know it's hard to > > > balance being welcoming to new reviewers and ensuring the patches > > > do get proper review in the end. > > > > I'm inclined to agree, this is a harsh approach. My personal > > method is to allow anyone to review, regardless of their > > credibility/trust status. I make a point not to hamper or > > criticise anyone that's genuinely tying to help, unless of f course > > they are dishing out bogus review comments, then those will need > > addressing, but only picking up even say 10% of the issues really > > isn't a problem. It doesn't matter how many points are picked-up > > or missed, we as Maintainers can always conduct an additional > > review or one in parallel. OK, so I should clarify that where I'm coming from is that I want not to have to review something if someone else has already done so. I suppose I should add that you mostly get these type of comments from me if I expected I could rely on your review but a random inspection found significant issues. > > I find additional reviewers particularly helpful if I'm overloaded, > > since I can then insist that the contributor fixes all outstanding > > review comments before I conduct my, hopefully thorough, review. > > > Indeed. From my POV the biggest problem is a shortage of reviewers, > and we should be working on getting that resolved. So wouldn't making review a precondition for patch acceptance be a strategy for at least helping with this? > In fact, most developers I'm working with simply are too scared to do > any reviews, feeling as they do not being qualified enough. > If we take the abovementioned route that's a sure way of putting them > off reviewing for good. I actually don't really believe people are afraid to review code. I think mostly (particularly in SCSI) they've got their hands full with constructing submissions and don't want to expend the additional bandwidth. James