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

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]

Message-ID: <1428410100.20888.83.camel@perches.com>
Date:	Tue, 07 Apr 2015 05:35:00 -0700
From:	Joe Perches <joe@...ches.com>
To:	Ingo Molnar <mingo@...nel.org>
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: 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)

On Tue, 2015-04-07 at 11:12 +0200, Ingo Molnar wrote:
> I don't think you have answered PeterZ's 
> legitimate technical question adequately:

As I wrote before, ~13000:180 is a big ratio.
http://www.kernelhub.org/?p=2&msg=718145

> 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.

I presume you mean file rather than function.

21 of the 55 files modified already used "return true"
or "return false" for other bool function returns.

Many of the 1/0 uses were in functions where the
function return type was changed from int to bool but
the return statements were unchanged.

Expectation and consistency matter.
To what degree is, as always, debatable.

Code that causes a reader to "stall" when reading is
generally not good.  

Patches that span subsystems, given the distribution
of interest and responsibilities in the kernel,
generally aren't possible to apply by any single
maintainer.

It's generally necessary to split even these admittedly
trivial patches by area of maintainership.

Bypassing actual maintainers by sending only to the
nominal trivial maintainer isn't good.

> In fact what are your technological justifications for doing 
> so many trivial patches in general?

Consistency improves reading speed and can help reduce
future defects.

> Please don't bother producing and sending me such trivial patches

My creation of these types of patches either singly
or in a series is fairly automated.

I will sed your name and email address out of the
scripts that generate the "To:" and "CC:" lists for
patches in the future.

If any other person with a MAINTAINERS entry wants not
to receive these types of patches from me, please let
me know privately.

> Pointing out this truth and protecting against such abusive flood of 
> trivial patches is not against the code of conduct I signed.

Jokes are hard.
"Be excellent to each other" can be too, but shouldn't be.
Manners and civility are important.
Yours, like mine, can always be improved.
We all should strive for that improvement.

cheers, Joe

--
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/