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 ESMTP id 5747AB28 for ; Thu, 29 May 2014 02:15:37 +0000 (UTC) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB363200A4 for ; Thu, 29 May 2014 02:15:35 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id id10so1316784vcb.27 for ; Wed, 28 May 2014 19:15:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1400925225.6956.25.camel@dabdike.int.hansenpartnership.com> Date: Wed, 28 May 2014 21:15:34 -0500 Message-ID: From: Rob Herring To: Paul Walmsley Content-Type: text/plain; charset=UTF-8 Cc: James Bottomley , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TOPIC] Encouraging more reviewers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, May 28, 2014 at 1:47 PM, Paul Walmsley wrote: > On Sat, 24 May 2014, James Bottomley wrote: > >> I'm sure there are many other things people could suggest. > > What's needed is to bring quality reviewers up to the same level of > recognition and control as maintainers. > > Ideally, maintainers would recognize quality reviewers, and list them in > the MAINTAINERS file - perhaps with an "R:" tag? Maintainers would be > expected to designate at least one quality reviewer, but ideally more, for > a given subsystem. > > Then we should require every patch to have at least one "Reviewed-by:", > aside from the maintainer's "Signed-off-by:" before being merged. This > "Reviewed-by:" could come from the maintainer, but ideally would come from > a quality reviewer. > > Patch submitters would need to get their patches reviewed by at least one > of the recognized reviewers before expecting it to be merged. > > Part of the goal here would also be to convert quality reviewers into > co-maintainers over time, so maintainership duties can be spread among a > larger group of people. What really needs to change here as we already essentially have this today. Getting more reviewer bandwidth is why we have 5 DT binding maintainers. DT bindings are a bit unique in that almost everything goes in thru other maintainers trees, so the role is almost entirely reviews. But what's to say a co-maintainers role is not solely reviews. How co-maintainers split up the load is really an internal decision among them. Do we really have people we trust to review that we wouldn't trust to be a co-maintainer? Rob