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

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 11/04/2015 03:22 AM, Markus Armbruster wrote:
>> Eric Blake <address@hidden> 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).

We're on the same page.

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

It would've been nice to get through the complete queue, but I'm a
horribly picky reviewer.  On the plus side, it hasn't been just for
making patches prettier; we've found quite a few additional things to
improve.

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

That's reassuring.

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

Your choice.  I probably wouldn't, because I figure that bug fixes that
impact users are pretty unlikely.  Fixes for stuff that breaks when you
do certain things in a schema we don't currently do are not critical,
and delaying them to the next cycle is just fine with me.

[...]