From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO0oT-0001aE-TI for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:57:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO0oR-0004E5-So for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:57:44 -0400 References: <1468501843-14927-1-git-send-email-caoj.fnst@cn.fujitsu.com> <57879CFA.9040700@redhat.com> <57884102.3050905@cn.fujitsu.com> <20160715104009.GE25692@stefanha-x1.localdomain> From: Cao jin Message-ID: <5788C334.7070008@cn.fujitsu.com> Date: Fri, 15 Jul 2016 19:04:20 +0800 MIME-Version: 1.0 In-Reply-To: <20160715104009.GE25692@stefanha-x1.localdomain> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] aio_ctx_check: follow CODING_STYLE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Eric Blake , qemu-devel@nongnu.org, qemu-trivial@nongnu.org, famz@redhat.com, stefanha@redhat.com, qemu-block@nongnu.org On 07/15/2016 06:40 PM, Stefan Hajnoczi wrote: > On Fri, Jul 15, 2016 at 09:48:50AM +0800, Cao jin wrote: >> On 07/14/2016 10:08 PM, Eric Blake wrote: >>> On 07/14/2016 07:10 AM, Cao jin wrote: >>>> replace tab with spaces >>>> >>>> Signed-off-by: Cao jin >>>> --- >>>> async.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> Whitespace-only changes are best done as part of a series that is >>> already touching nearby code for other reasons (depending on the size of >>> the whitespace changes and on the rest of your patch, it may be okay to >>> squash the whitespace change in place, or better to split into separate >>> patches to make review of both patches easier). Otherwise, it just >>> makes 'git blame' output dirtier. >> >> I see. >> Since async.c & aio-posix.c are belong to the same maintaiers, so, Fam & >> Stefan, is it ok to squash this into that "remove useless parameter" patch? >> If not, we can just forget this one. > > The "remove useless parameter" patch doesn't touch the function you are > modifying here. Please don't squash the patches. > > Since you have already posted this patch I will merge it. In the future > please don't submit whitespace changes, tiny coding style cleanups, etc > in by themselves. > > Thanks for all your contributions. I do not want to discourage you but > my view is that code changes should only be made if they fix a bug, > improve performance measurably, add a feature, or significantly improve > the code. > > Every patch has a cost in terms of code review, merging/testing, backporting, > bisecting, documentation, etc. We could discuss each of these in detail > but basically a code change creates work or takes time from one or more > people in these areas. > > In a perfect world with unlimited resources all patches would be equally > welcome. Due to limited resources it's best to submit the types of > patches I mentioned above where the cost/benefit ratio is favorable. > > Thanks, > Stefan > Thanks Stefan, and sorry for the inconvenience brought to you. I thought this kind of tiny things would be very simple for maintainers, now I understand -- Yours Sincerely, Cao jin