> How many times have I told you to include the reason for your patches > in your proposed commit message? Will it be useful to look again at the involved circumstances? > Too often. Did I answer any concerns partly? > Many people do not know that a generic kmalloc does a dump_stack() on OOM. Do you see a need to represent such information better? Is it expected that the function “devm_kzalloc” has got a similar property? > That information should be part of the commit message. How do you think about to share it also from any reference documentation in a clearer way? Do we stumble on a target conflict in this case? I am generally trying to improve the software situation to some degree. I prefer then to work with safe information sources. Unfortunately, I might have not reached a desired confidence level here for a more detailed commit message. I assume that software development efforts could increase in significant ways if something should be improved further in a direction I hope. But this could mean that time frames will grow for corresponding clarifications. * Does such a situation block progress on the deletion of other remaining questionable error messages? * Would you like to increase the software development attention anyhow? By the way: It seems that my update suggestion for the directory “omapfb/dss” could be superseded by the patch “omapfb: dss: Do not duplicate features data” from Ladislav Michl. https://patchwork.kernel.org/patch/10082027/ https://lkml.kernel.org/r/<20171129123308.GA26578@lenoch> Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
