>> There can be additional means be used to reduce the probability >> of undesired side effects. > > Irrelevant, I got an other opinion here. > it doesn't fix a bug, Did I suggest to correct a coding style “bug”? > nor dramatic improvement. I agree that the change could be small only for this software module alone. I guess that we discuss not only change patterns for this one but also other affected modules here (besides a concrete example). The result summary might be more significant overall. >>> It must be "almost perfect" for such a code refactoring. >> >> Can you get the impression that the shown transformation patterns were correctly >> applied for the source file “sound/pci/nm256/nm256.c”? > > Impression doesn't matter. It seems then that you can not get the kind of information you might be looking for at the moment from me (alone). > The question is whether it's 100% correct or not in such a case. Would any other source code reviewers like to provide a corresponding acknowledgement for concrete changes? >> Are there any more software developers and code reviewers available >> who would like to point another programming mistake out for this Linux module? > > If you have find such, then it's fine, you can get your patches > reviewed and more assured. I hope that mailing list readers could offer something. > But in the current situation, no one else is interested in it, > and that's going to nowhere. Did this software module become “too old”? > The *really* trivial ones were applied. The rest are not. Can higher level transformation patterns become easier to accept by any other means? >> Do you need any more information to see and eventually accept the sense again? > > No. This kind of code refactoring has no more information. > It's a "trivial" change, after all. Would you like to distinguish the possible update steps better to avoid further confusion around “triviality”? >> Are you using a continuous integration system? > > Not really in my side. But there are others doing that. How much does the omission of such an useful development tool influence your concerns? Would you like to improve the software situation in any ways there? 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
