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.