From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVYZQ-0007eI-9Z for qemu-devel@nongnu.org; Thu, 25 Apr 2013 22:39:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UVYZP-0004lE-8K for qemu-devel@nongnu.org; Thu, 25 Apr 2013 22:39:32 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:55594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVYZM-0004eV-QU for qemu-devel@nongnu.org; Thu, 25 Apr 2013 22:39:31 -0400 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 26 Apr 2013 12:32:02 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id 8505E2BB0050 for ; Fri, 26 Apr 2013 12:39:17 +1000 (EST) Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3Q2PVNZ18808902 for ; Fri, 26 Apr 2013 12:25:31 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3Q2dHEW016385 for ; Fri, 26 Apr 2013 12:39:17 +1000 Message-ID: <5179E8D2.7070603@linux.vnet.ibm.com> Date: Fri, 26 Apr 2013 10:39:14 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <2d4c5e75a5fa710d73fa4ffae03f4c143ba66519.1366817130.git.phrdina@redhat.com> <517862AC.3030500@redhat.com> <5178D407.3010900@linux.vnet.ibm.com> <51791FBA.4030005@redhat.com> In-Reply-To: <51791FBA.4030005@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 04/12] qapi: Convert delvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: lcapitulino@redhat.com, kwolf@redhat.com, Pavel Hrdina , qemu-devel@nongnu.org, armbru@redhat.com 于 2013-4-25 20:21, 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. > OK, I'll send out 2 serial clean the common part. Pavel, please wait for mine serial before v3. -- Best Regards Wenchao Xia