> Your patches happen to modify code maintained by me. From my > perspective the value of the changes made by them is marginal. Thanks for another bit of interesting information. > Nevertheless, I might take them if you made my life somewhat easier, I am also looking for further approaches to help you there. > so I've tried to tell you politely how to do that. This feedback is generally fine. > If you're not willing to do it, My willingness is depending on also some factors. > though, this is where it ends. I hope that a bit more clarification can improve the situation. > And attempts to convince me that I may not want my life to be easier > after all are not likely to succeed. We usually want that life will become more comfortable. I chose to contribute something to Linux source files for this purpose. My knowledge evolved in the way that I am using some tools for static source code analysis. Such advanced tools can point various change opportunities out. I picked a few special search patterns up. It happened then that hundreds of source files were found which contain update candidates. I am trying to inform the corresponding developers about improvement possibilities in affected systems. Further challenges are relevant then as usual. * Handling of the search process and their results * Communication between contributors Search patterns can occasionally be categorised as "too special". The software technology contains also the risk for showing "false positives". The reactions of code reviewers are varying between rejection and acceptance. Now I would like to determine again which details of the proposed changes have got a higher chance for acceptance. The discussed concrete patch series is just another example for usual difficulties or more interesting software development challenges. I hope that they can be resolved in a systematic way. I sent analysis results as a series of small software updates. I find it important to understand them also in the way that they belong to software design patterns. I can imagine that it is harder to recognise the involved patterns from the presented combination of update steps. Would you like to check and clarify these patterns once more before the desired improvements will happen (in a software area you maintain)? So there are further constraints to consider. My software development experience leaded me to a very specific kind of patch granularity here. My software development interest evolved also in the way that I dared to fiddle with the source files "drivers/acpi/processor_perflib.c" and "drivers/acpi/processor_throttling.c" yesterday. The consequence is that I would to publish a corresponding series of 30 update steps for integration into another source code repository. It seems that I need to wait a bit more for the next contribution attempt before the change acceptance will fit to such an approach. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
