linux-kernel - 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)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Apr 2015 11:12:46 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
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)

* Joe Perches <joe@...ches.com> wrote:

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