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