From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755264AbdK1Lhw (ORCPT ); Tue, 28 Nov 2017 06:37:52 -0500 Received: from mx2.suse.de ([195.135.220.15]:50252 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932287AbdK1Lhu (ORCPT ); Tue, 28 Nov 2017 06:37:50 -0500 Date: Tue, 28 Nov 2017 12:37:46 +0100 Message-ID: From: Takashi Iwai To: SF Markus Elfring Cc: alsa-devel@alsa-project.org, Arvind Yadav , Jaroslav Kysela , Takashi Sakamoto , kernel-janitors@vger.kernel.org, LKML Subject: Re: ALSA: nm256: Fine-tuning for three function implementations In-Reply-To: <1547a4c2-5b70-e3a3-b482-d28c538e615c@users.sourceforge.net> References: <24f8c777-1eb4-e7e7-9371-79f32700c9dc@users.sourceforge.net> <2cbef557-5f89-c630-e108-14ef2ce6b41a@users.sourceforge.net> <1547a4c2-5b70-e3a3-b482-d28c538e615c@users.sourceforge.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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