From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753045AbbDGJ1i (ORCPT ); Tue, 7 Apr 2015 05:27:38 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:33674 "EHLO mail-wg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751242AbbDGJ1e (ORCPT ); Tue, 7 Apr 2015 05:27:34 -0400 Date: Tue, 7 Apr 2015 11:27:30 +0200 From: Ingo Molnar To: Joe Perches Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Ingo Molnar , Greg Kroah-Hartman , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" Subject: Re: about the flood of trivial patches and the Code of Conduct (was: Re: [PATCH 19/25] sched: Use bool function return values of true/false not 1/0) Message-ID: <20150407092729.GA10226@gmail.com> References: <93bd3fb8db14c75508f7169840824539a3f89606.1427759010.git.joe@perches.com> <20150331085320.GR27490@worktop.programming.kicks-ass.net> <20150331090349.GA16604@gmail.com> <1427820400.10376.23.camel@perches.com> <20150407091246.GA9673@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150407091246.GA9673@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Ingo Molnar wrote: > > * Joe Perches wrote: > > > On Tue, 2015-03-31 at 11:03 +0200, Ingo Molnar wrote: > > > * Peter Zijlstra wrote: > > > > On Mon, Mar 30, 2015 at 04:46:17PM -0700, Joe Perches wrote: > > > > > Use the normal return values for bool functions > > > > > > > > > > Update the other sets of ret in try_wait_for_completion. > > > > > > > > I'm missing a why; why are you doing this? > > > > > > Let me guess: Joe Perches is suffering from 'trivialititis': a > > > sickness that prevents a non-newbie kernel developer from raising > > > beyond churning out a flood of trivial patches and creating > > > unnecessary churn for other developers with these borderline > > > useless patches? > > > > > > Linux is a meritocracy, not a bureaucracy. > > > > Good morning Ingo. > > > > As you are a signer of that "code of conflict" patch, > > I'll be mildly amused, but not surprised, if you are > > among the first participants. > > So as a reply to my joke directed against your (costly: see below) > flood of trivial and somewhat bureaucratic patches that PeterZ > complained about, which reply of mine aimed at getting you to change > from your many years old pattern of producing trivial patches towards > producing more substantial patches, causes you to issue a threat of > bureaucratic action against me? > > Wow. > > I'd also like to stress that I don't think you have answered PeterZ's > legitimate technical question adequately: what are the technological > justifications for doing this 25 patches series - returning 0/1 or > true/false is clearly a matter of taste unless mixed within the same > function. In fact what are your technological justifications for doing > so many trivial patches in general? > > Please don't bother producing and sending me such trivial patches > unless they: > > - fix a real bug (in which case they are not trivial patches anymore) > > - or are part of a larger (non-trivial!) series that does some real, > substantial work on this code that tries to: > > - fix existing code > > - speed up existing code > > - or expand upon existing code with new code > > - turn totally unreadable code into something readable > (for example in drivers/staging/) > > The reason I'm not applying your patch is that trivial patches, even > if they seem borderline useful, with no substance following them up, > often have more costs than benefits: > > - they lead to pointless churn: > > - they take up Git space (and bandwidth) for no good reason > > - they slow down bisection of real changes > > - they take up (valuable!) reviewer bandwidth > > - they take up maintainer bandwidth Not to mention that one of your trivial patches in this series actually introduced a bug: lkml.kernel.org/r/1427867186.18175.60.camel@perches.com Which additional risk adds to the cost side of the equation as well. Thanks, Ingo