>> I am trying to improve various open issues also in Linux source files. >> > That the fact that you see issues (in these particular cases) while > others do not I guess that the discussed "story" affects more challenges in communication and different opinions about where to invest software development attention. > indicates that the commit summary could be explained better. I imagine that there are a few improvement possibilities left over. > A good commit summary should provide enough information to do that This advice is generally fine. > and make people _want_ the patch. I guess that this expectation can become a research topic for some knowledge fields, can't it? There are update suggestion where the probability for acceptance is higher than for others. Some maintainers have got their own difficulties with changes when they categorise them as "ordinary clean-up". > From my limited experience through your patches (just skimmed a few) Thanks for your general interest. > you seems to be describing what the patch does My collection of update suggestions is evolving over some source code search patterns. I find that this approach fits to the recommended imperative wording style according to document "SubmittingPatches", doesn't it? I dared also some deviations or variations already. > as opposed to why it does it and why should one find it interesting/wanted. I am trying to express also this information to some degree. 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
