>> I am a bit surprised that you do not like such source code fine-tuning. > > It's moving stuff around for no real reason, why would I like it? Can such fine-tuning result in positive effects for the run-time behaviour? > Reading and reviewing and applying this type of stuff takes away from > the time I have to spend reviewing and applying actual code fixes from > other developers who are doing real and useful work. I am aware that a lot of open issues are competing for your precious software development attention. > Remember maintainer's time is our most limited resource right now. That is mostly usual. > You are abusing that by wasting their time for no valid reason. I find a couple of my update suggestions still valid. I agree that the importance of proposed changes is varying. >> Will related software improvements get another chance later (eventually together >> with other changes)? > > Define "improvements". Did you fix an obvious bug? Maybe. - It depends on the error classes you are interested in at the moment. > Did you speed up the code in a measurable way? My suggestions can result in measurable differences. > Did you make the code easier to understand somehow? > For this patch you did none of these things. Thanks for your view on my approach. Will it become acceptable to reduce the scope for any more variable definitions in further function implementations? > Code in staging needs to be moved out of staging, and this patch does > nothing toward achieving that goal and it wastes people's time reviewing > it to see if it is correct or not. I am curious on the ways the discussed software can evolve further. 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
