From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVLAy-0003Mr-TA for qemu-devel@nongnu.org; Thu, 25 Apr 2013 08:21:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UVLAt-00029T-Vg for qemu-devel@nongnu.org; Thu, 25 Apr 2013 08:21:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVLAt-00029P-Ni for qemu-devel@nongnu.org; Thu, 25 Apr 2013 08:21:19 -0400 Message-ID: <51791FBA.4030005@redhat.com> Date: Thu, 25 Apr 2013 06:21:14 -0600 From: Eric Blake MIME-Version: 1.0 References: <2d4c5e75a5fa710d73fa4ffae03f4c143ba66519.1366817130.git.phrdina@redhat.com> <517862AC.3030500@redhat.com> <5178D407.3010900@linux.vnet.ibm.com> In-Reply-To: <5178D407.3010900@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2EMDTVMLGCSIMUQOATECL" Subject: Re: [Qemu-devel] [PATCH v2 04/12] qapi: Convert delvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: lcapitulino@redhat.com, kwolf@redhat.com, Pavel Hrdina , qemu-devel@nongnu.org, armbru@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EMDTVMLGCSIMUQOATECL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/25/2013 12:58 AM, Wenchao Xia wrote: >=20 >>> + 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 spo= t. >> 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. >=20 >> [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, althoug= h > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2EMDTVMLGCSIMUQOATECL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJReR+6AAoJEKeha0olJ0Nq6OEH/iZm/DbEnuK++uT+tETt5GHS zT7cEjJvIJg4HF7LBoOBixiuVk0ARn76/nw2apor+Csa5K8KDLzTF2PV5zzoa5ba 1jIXwZZ1mXkj/rPorMZait0s8knXuRTTvSOg3jEfpuOLriRWx9zR1JTC/Pz5/k7K G237atWDMy6BrSGAfQk4ltj+gAQ3sXx7BkEDMkl+KY/eqcmgtycUqyOqsrAMvogN 1G/+hXa2ANoM4d5vTSEiGM+AbMt5RQRoG25ZDEMLi1HRvljgDCmPY/iWgf7oKLuD iQy45WD4PJJuLVIpgtD1vThO4IIk72EsM6Ghe6E6K/LetB+tc3261VXprOkDNGk= =KN0I -----END PGP SIGNATURE----- ------enig2EMDTVMLGCSIMUQOATECL--