From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752905AbbDGJMz (ORCPT ); Tue, 7 Apr 2015 05:12:55 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:38376 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750778AbbDGJMv (ORCPT ); Tue, 7 Apr 2015 05:12:51 -0400 Date: Tue, 7 Apr 2015 11:12:46 +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: 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: <20150407091246.GA9673@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1427820400.10376.23.camel@perches.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 * 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 conduct I signed. Thanks, Ingo