Re: [Qemu-devel] [Qemu-block] [PATCH] aio_ctx_check: follow CODING_STYLE

[Cao jin <caoj.fnst@cn.fujitsu.com>]

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 <caoj.fnst@cn.fujitsu.com>
>>>> ---
>>>>    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