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
