On Tue, 28 Nov 2017 10:50:21 +0100, SF Markus Elfring wrote: > > >> There can be additional means be used to reduce the probability > >> of undesired side effects. > > > > Irrelevant, > > I got an other opinion here. Not from me. > > it doesn't fix a bug, > > Did I suggest to correct a coding style “bug”? No. A coding style issue is never a 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. No. > >>> 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). No, the patch itself speaks. > > 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? If you get more reviewed-by from others, it means already it's safer to apply. Then I can take it. But without that, it's obviously no material to take. > >> 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. Let's hope. > > 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”? Mostly the hardware is too old, or the change itself isn't interesting enough. > > The *really* trivial ones were applied. The rest are not. > > Can higher level transformation patterns become easier to accept > by any other means? Only if it's assured to work and not to break anything else. > >> 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”? Learn from the past. > >> 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? Can't judge unless I really see / use it. > Would you like to improve the software situation in any ways there? I *hope*, but only when it's not too annoying. Takashi -- 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
