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
2015-04-07T09:12:55Z

* 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

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