Messages in this thread | | | Date | Tue, 7 Apr 2015 11:27:30 +0200 | From | Ingo Molnar <> | 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) |
| |
* Ingo Molnar <mingo@kernel.org> wrote:
> > * Joe Perches <joe@perches.com> wrote: > > > On Tue, 2015-03-31 at 11:03 +0200, Ingo Molnar wrote: > > > * Peter Zijlstra <peterz@infradead.org> 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
| |