Re: [Qemu-devel] [PATCH v2 04/12] qapi: Convert delvm

[Eric Blake]

On 04/25/2013 12:58 AM, Wenchao Xia wrote:
> 
>>> +        char buf[256];
>>
>> I know this fixed-size buffer is just a copy-and-paste from other code
>> that displays snapshot information, but I really hate it. On the other
>> hand, I can tolerate if we have it as an intermediate step between two
>> series that both land in the same release.
>>
>> If your series goes in first, Wenchao's series that cleans up the
>> fixed-size buffer will need to be rebased to tweak this additional spot.
>>   If Wenchao's patches go in first, then you will have a bit of rebase
>> work to do.  Since we are already deferring this series into 1.6, I
>> think it would be nice to post a unified series of the best of both
>> authors, rather than continuing to waffle on what should go in first.
>   That would be a very long serial, taking time to rebase for any code
> change in it, that is why I haven't consider it before.

s/serial/series/

But it would at least have the end goal in mind, instead of trying to
debate what the end goal is between two different series.

> 
>> [And if I keep saying that often enough, I may end up getting my hands
>> dirty and becoming the person that posts such a unified patch, although
>   Pls don't, I guess it would not be a good experience working in a
> long serial which may need modification later.

Sometimes, letting an additional author join in on attempting to post
patches can be productive.  But I certainly don't want to make it feel
like a hostile takeover - we've got plenty of time before 1.6, so I
don't mind letting you work through a few more revisions of the series.

>   My serial serves mainly for block image's info querying, different
> with Pavel, one serial fixing all is not easy to make.
>   Instead, I'll send out small serial change the common part:
> 1 better bdrv_snapshot_find().
> 2 hmp/qemu-img dumping info code().
>   Then we rebase on it, as two serial, do you think it is OK?

Splitting into pieces is also okay, as long as the pieces make sense.  I
see several piecemeal changes being attempted between the two series
with several conflicts if we don't factor out common parts, such as
moving snapshot-related code into a new file, making snapshot lookup
cleaner, removing hard-coded length limits on HMP snapshot display.
Yes, getting the common parts clean as one series, then doing two more
relatively-independent series of 1. better query output, 2. QMP
counterpart to snapshot manipulations, is probably workable.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature