Re: [Qemu-devel] [PATCH v9 00/27] alternate layout (post-introspection cleanups, subset C)

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]

On 11/04/2015 03:22 AM, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
> 
>> 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.
> 
> Hard freeze is next week.
> 
> PATCH 01-07+09 are simple cleanups, bug fixes tests and documentation,
> which makes them obvious candidates for 2.5.
> 
> 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.
> 
> The remainder of the series doesn't feel like post hard freeze material.
> 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.

> 
> 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).

> 
>> Patch 23 still uses tag_member.type == 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.
> 
> I'll continue reviewing meanwhile.
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]