From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753350AbbDGJg3 (ORCPT ); Tue, 7 Apr 2015 05:36:29 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:35972 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752816AbbDGJg0 (ORCPT ); Tue, 7 Apr 2015 05:36:26 -0400 Date: Tue, 7 Apr 2015 11:36:21 +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 Conflict (was: Re: [PATCH 19/25] sched: Use bool function return values of true/false not 1/0) Message-ID: <20150407093621.GA10537@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 s/Conduct/Conflict * 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 > > there's literally a million borderline pointless cleanup patches that > could be done on the kernel, and we really don't want to add a million > commits to the kernel tree... > > I don't think your 25 patches long trivial series is defensible from a > kernel contributor who has thousands of commits in the mainline kernel > already: you are clearly not a kernel newbie anymore who needs to > learn the ropes through simple patches and whose initially trivial > patches maintainers will nurture in the hope of gaining a future > contributor who will be a net benefit in the future... > > I also think you are beginning to abuse the openness of kernel > maintainers to apply trivial patches, and I don't think it's useful to > point out such abuse before it gets worse. > > My (repeated) advice to you is that you should try to raise beyond > newbie patches and write something more substantial that helps Linux: > > - take a look at the many bugs on bugzilla.kernel.org and try to > analyze, reproduce or fix them > > - go read kernel code, understand it and try to find real bugs. > > - go test the latest kernels and find bugs in it. The fresher the > code, the more likely it is that it has bugs. > > - go read kernel code and try to expand upon it > > Fortunately it's not hard to contribute to the kernel once you are > beyond the 'newbie' status: there's literally an infinite amount of > work to be done on the kernel, and I welcome productive contributions > - but churning out trivial patches with no substantial patches > following them up is not productive and in fact (as pointed out above) > they are harmful once you are not a totally fresh newbie kernel > developer anymore... > > Pointing out this truth and protecting against such abusive flood of > trivial patches is not against the 'Code of Conflict' I signed. > > Thanks, > > Ingo