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