Eric Blake <ebl...@redhat.com> writes: > On 11/04/2015 03:22 AM, Markus Armbruster wrote: >> Eric Blake <ebl...@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).
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. [...]
