s/Conduct/Conflict * Ingo Molnar <mi...@kernel.org> wrote:
> > * Joe Perches <j...@perches.com> wrote: > > > On Tue, 2015-03-31 at 11:03 +0200, Ingo Molnar wrote: > > > * Peter Zijlstra <pet...@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 > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
