[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-block] [Qemu-devel] [PATCH] aio_ctx_check: foll

From: Cao jin
Subject: Re: [Qemu-trivial] [Qemu-block] [Qemu-devel] [PATCH] aio_ctx_check: follow CODING_STYLE
Date: Fri, 15 Jul 2016 19:04:20 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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 <address@hidden>
   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, 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]