From: Takashi Iwai <tiwai@suse.de>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: alsa-devel@alsa-project.org,
Arvind Yadav <arvind.yadav.cs@gmail.com>,
Jaroslav Kysela <perex@perex.cz>,
Takashi Sakamoto <o-takashi@sakamocchi.jp>,
kernel-janitors@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: ALSA: nm256: Fine-tuning for three function implementations
Date: Tue, 28 Nov 2017 12:37:46 +0100 [thread overview]
Message-ID: <s5hy3mqr5v9.wl-tiwai@suse.de> (raw)
In-Reply-To: <1547a4c2-5b70-e3a3-b482-d28c538e615c@users.sourceforge.net>
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
next prev parent reply other threads:[~2017-11-28 11:37 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 17:05 [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations SF Markus Elfring
2017-11-16 17:07 ` [PATCH 1/2] ALSA: nm256: Adjust five function calls together with a variable assignment SF Markus Elfring
2017-11-16 17:08 ` [PATCH 2/2] ALSA: nm256: Use common error handling code in snd_nm256_probe() SF Markus Elfring
2017-11-16 17:15 ` [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations Takashi Iwai
2017-11-16 17:48 ` SF Markus Elfring
2017-11-16 18:54 ` Takashi Iwai
2017-11-16 19:30 ` SF Markus Elfring
2017-11-28 7:46 ` Takashi Iwai
2017-11-28 8:19 ` SF Markus Elfring
2017-11-28 9:10 ` Takashi Iwai
2017-11-28 9:50 ` SF Markus Elfring
2017-11-28 11:37 ` Takashi Iwai [this message]
2017-11-28 12:33 ` SF Markus Elfring
2017-11-28 12:46 ` Takashi Iwai
2017-11-28 13:00 ` SF Markus Elfring
2017-11-28 13:06 ` Takashi Iwai
2017-11-28 13:17 ` SF Markus Elfring
2017-11-28 13:38 ` Takashi Iwai
2017-11-28 14:19 ` SF Markus Elfring
2017-11-28 14:27 ` Takashi Iwai
2017-11-28 14:33 ` SF Markus Elfring
2017-11-28 14:38 ` Takashi Iwai
2017-11-28 14:44 ` SF Markus Elfring
2017-11-28 14:53 ` Takashi Iwai
2017-11-28 15:01 ` SF Markus Elfring
2017-11-28 15:21 ` Takashi Iwai
2017-11-28 16:15 ` SF Markus Elfring
2017-11-28 16:27 ` Takashi Iwai
2017-11-28 16:40 ` SF Markus Elfring
2017-11-28 16:44 ` Takashi Iwai
2017-11-28 17:15 ` SF Markus Elfring
2017-11-28 18:35 ` Takashi Iwai
2017-11-28 19:08 ` SF Markus Elfring
2017-11-28 19:43 ` Takashi Iwai
2017-11-28 19:48 ` SF Markus Elfring
2017-11-28 19:54 ` Takashi Iwai
2017-11-28 19:57 ` SF Markus Elfring
2017-11-28 20:00 ` Takashi Iwai
2017-11-28 20:18 ` SF Markus Elfring
2017-11-28 20:25 ` Takashi Iwai
2017-11-28 20:32 ` SF Markus Elfring
2017-11-29 10:34 ` SF Markus Elfring
2017-11-28 12:33 ` [alsa-devel] " Ondrej Zary
2017-11-28 13:10 ` SF Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hy3mqr5v9.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=arvind.yadav.cs@gmail.com \
--cc=elfring@users.sourceforge.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=o-takashi@sakamocchi.jp \
--cc=perex@perex.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).