From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztzdc-00056h-3Z for qemu-devel@nongnu.org; Wed, 04 Nov 2015 10:06:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtzdY-0007GL-S8 for qemu-devel@nongnu.org; Wed, 04 Nov 2015 10:06:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtzdY-0007GH-LE for qemu-devel@nongnu.org; Wed, 04 Nov 2015 10:06:08 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 34227C0D61A6 for ; Wed, 4 Nov 2015 15:06:08 +0000 (UTC) References: <1446618049-13596-1-git-send-email-eblake@redhat.com> <87bnbarrma.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <563A1EDA.7090605@redhat.com> Date: Wed, 4 Nov 2015 08:06:02 -0700 MIME-Version: 1.0 In-Reply-To: <87bnbarrma.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8btWx2iejNG4RFXIAicWkuj8G0f99SexN" Subject: Re: [Qemu-devel] [PATCH v9 00/27] alternate layout (post-introspection cleanups, subset C) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8btWx2iejNG4RFXIAicWkuj8G0f99SexN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/04/2015 03:22 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> No pending prerequisites; based on qemu.git master >> >> Also available as a tag at this location: >> git fetch git://repo.or.cz/qemu/ericb.git qapi-cleanupv9c >> >> and will soon be part of my branch with the rest of the v5 series, at:= >> http://repo.or.cz/qemu/ericb.git/shortlog/refs/heads/qapi >> >> v9 notes: >> More patches added, and several reorganized. Lots of new patches >> from Markus, although not in the order originally proposed. >> >> The first 8 patches are fairly straightforward, and could probably >> be taken as-is. Patch 9 is a rewrite of v8 4/17, but in the opposite >> direction (document that no sorting is done, rather than attempting >> to sort), so it may need further fine-tuning. Patches 12-21 >> represents a fusion of Markus' and my attempts to rewrite v5 7/17 >> into a more-reviewable set of patches, and caused further churn >> later in the series. >=20 > Hard freeze is next week. >=20 > PATCH 01-07+09 are simple cleanups, bug fixes tests and documentation, > which makes them obvious candidates for 2.5. >=20 > PATCH 08 is a feature, but harmless enough. I still don't like it much= , > but I said I'll take it. Best before the hard freeze, though. >=20 > The remainder of the series doesn't feel like post hard freeze material= =2E > What do you think? My patches _were_ posted prior to soft freeze, even if the initial review did not happen then; so on that grounds, you can continue to take as much as you want until hard freeze actually happens. But it gets harder and harder to justify, and the process definitely changes when hard freeze hits (no features, regardless of when they were first posted, but only bug fixes). So it sounds like we won't get all of my qapi queue in 2.5. My goal had originally been to get netdev_add to be fully introspectible, but that's still more than 20 patches away; and the status quo of learning about the netdev_add command being less than perfect isn't a regression per se. So you are right that the later patches in my series can probably wait until 2.6. I'm fine with your judgment on where you want to draw the line of what will make soft freeze. >=20 > I don't have the complete picture of your queue. Please double-check > whether you got anything in it that affects introspection, because > changing introspection will become super awkward as soon as 2.5 is out.= Patches 8 and 9 in this series have to make 2.5 (and we're in agreement that while patch 9 is not quite baked in this v9 spin, we should still have plenty of time to get it done before hard freeze). The only other pending patch I have previously posted from my queue that touches qapi-introspect.py does not actually change introspection output: http://repo.or.cz/qemu/ericb.git/commitdiff/5c25f6eb95, first posted at: https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05441.html so we should be fine on that front. Introspection itself is fine, and the bulk of my focus has been on cleanups to the internals and extensions of the internals to allow netdev_add to be introspectible. I can certainly browse through my pending queue to double-check if any of the patches there qualify as bug fixes that are safe even during hard freeze, and focus on hoisting them to the front of the review queue, once we get 1-9 of this series ready for pull. And obviously that should mean user-triggerable bugs under existing .json files (patches like 24/27 that fix design bugs in the generator, but which don't affect any user besides the testsuite, aren't hard-freeze material - either it makes soft freeze or it defers to 2.6). >=20 >> Patch 23 still uses tag_member.type =3D=3D None; I ran out of time to >> work on Markus' idea of providing an instance of QAPISchemaBuiltinType= >> to fill the role for 'qtype_code' without being exposed through .json >> files and without breaking the invariant of a valid member.type after >> check(), and wanted to get the rest of the series started under revew.= >> So I may need a followup patch or even a v10 of the later half of >> this series after exploring that idea more. >=20 > I'll continue reviewing meanwhile. >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --8btWx2iejNG4RFXIAicWkuj8G0f99SexN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWOh7aAAoJEKeha0olJ0Nqp5oH/16coMFSEbiVU1Yuv/wYFQnI npXJQt0JEfy0op03QS5mfdEDqTPLH8n3q4IwbfVUjxwMp0NQKUH2re6zF6fNoZgb nhF5u159Pxa9K0JYqH0Isg+vAA2gBuiVJWZWiqngM8Hzf7Soln6Jp0GY81iuQ3O/ cgYBsDV1Mjay0cxML97t57tGCZfDYEukCajv94jRBip8k56BwYDk9o/DU41zb0ap r5k6790rfK/JQd9Lf5zPSvzSQyc4EocJrzL90PbqMQeckAiqpPz1C50/J2FTMEWo CbhqeY9kCJmm9ELFxXP3FD7F62yVgwUa+mVRulcjRcQGXlBtR7S/tCjTHn3TV3g= =dt0/ -----END PGP SIGNATURE----- --8btWx2iejNG4RFXIAicWkuj8G0f99SexN--