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 3C59A8A7 for ; Fri, 30 May 2014 02:25:19 +0000 (UTC) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 297CD1FA42 for ; Fri, 30 May 2014 02:25:17 +0000 (UTC) Message-ID: <5387EBB3.8060800@huawei.com> Date: Fri, 30 May 2014 10:23:47 +0800 From: Li Zefan MIME-Version: 1.0 To: Greg KH References: <1400925225.6956.25.camel@dabdike.int.hansenpartnership.com> <20140524111927.GA3455@katana> <4700397.FLxRVChBLf@vostro.rjw.lan> <1401294020.13546.95.camel@dhcp-9-2-203-236.watson.ibm.com> <20140528162833.GA23815@thin> <20140528233145.GA14933@cloud> <1401344001.27691.4.camel@dabdike> <20140529233459.GD11741@kroah.com> In-Reply-To: <20140529233459.GD11741@kroah.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 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 2014/5/30 7:34, Greg KH wrote: > On Thu, May 29, 2014 at 10:13:21AM +0400, James Bottomley wrote: >> I suspect, but cannot prove, it is somewhat driven by the patch >> statistics. I know in Parallels, I track features accepted into the >> kernel, not patches, but we do have a patch metric as well for people >> who do incidental bug fixing as they push features, so we're not 100% >> pure on this. >> >> When I recently gave a comparison of OpenStack and the Kernel, one thing >> that stood out starkly was that they just don't have our volume of one >> line, one patch per file hundreds of times and trivial changes, so we >> definitely have a problem in this area. >> >> The reason OpenStack has so few trivial and multiply split patches is >> mostly grounded in the difficulty of submitting a patch to their tree. > > And I would argue that this is going to be a long-term problem for them. > >> Just preparing it for gerrit takes a long time (around ten minutes per >> patch), which really reduces the volume of trivial patches, just because >> no-one has that much energy (although some would argue it reduces the >> volume too far). >> >> It's human nature to spend more time on the easy problems, so a flood of >> trivial patches which are "obviously" correct is easier to review and >> include than one patch which alters something deep within mm and needs >> careful thought. At best, excessively split trivial patches are a >> dilution of our review effort and at worst, they're actively sucking >> people away from tackling the hard problems. > > I have not heard of these "cleanup" patches taking anyone's review > cycles up for the "harder" patches, do you have examples of it? > > In fact, I would argue the fact that we do so easily accept cleanups > across the board that keeps our developer community engaged and new > people joining in easy. It's _really_ hard to get involved in > OpenStack, by design. The kernel is not that way, and hopefully never > will be, as we want to succeed... > Yeah, we've been encouraging our people working on upstream kernel, and many of them started by making cleanup patches, but then they moved to bug fixes and other work. However it's hard to ask them to join a subsystem development by also reviewing patches. I can think of some possible reasons: - Not confident enough? - Language barrier. - Asian culture issue. We don't like discussions, so we tend to avoid discussing and arguing with other kernel developers and maintainers. - Credit and the feeling of achievement is not high in reviewing patches. - We are busy with internal jobs. :)