Re: [Qemu-devel] [PATCH v6 00/36] drop qapi nested structs

[Markus Armbruster]

General question first: through which tree should this go?

MAINTAINERS doesn't cover the QAPI generators.  Closest related stanza
is QAPI (Luiz, Michael R.).  Should it cover the generators?  Next
closest is QAPI Schema (Luiz, you, myself).

For completeness: because we touch qmp_query_pci_bridge() and
qmp_query_pci_devices(), get_maintainers.pl also fingers the PCI tree.

If nobody objects, I can take it through my tree.  Cc'ing the
maintainers just mentioned to give them a chance to chime in.

Eric Blake <address@hidden> writes:

> On 04/28/2015 08:02 AM, Markus Armbruster wrote:
>
>>> v6 changes are noted in each patch; in particular, several new
>>> patches were added (additional tests, split some patches, conversion
>>> to 'struct' instead of 'type'). But most of the changes were in
>>> direct response to review comments or rebase fallout, so I kept
>>> in Reviewed-by markings where possible, to help focus review on
>>> the remainder.
>> 
>> Looks good to go to me, except for new PATCH 37, where I suggested a
>> small change.  Shouldn't hold up this series.  If any other patch still
>> lacks my R-by, let me know.
>
> Easier as a followup? Respin just the one patch? Or bite the bullet and
> rebase the entire series (fixing the other trivial items and adding R-b
> along the way)?

I think we can either

* Respin, but keep the changes really simple.  Feel free to leave some
  issues to followup patches.

* Merge the series except for PATCH 37, with trivial touch-ups on
  commit.  Followup patches to address any remaining issues.

  If we take it through my tree, I'm happy to do the touch-ups.

>>> I wrote another patch while working on this series, but it was
>>> independent enough that I posted it separately (although I based
>>> the documentation in this patch as if that, or Markus' alternative,
>>> had been applied):
>>> https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00373.html
>> 
>> Both need a trivial respin to correct a pasto.  Yours has a more
>> elaborate commit message, and a test.  Mine is less code, in part
>> because it uses a single qnull object instead of allocating one for each
>> use, and it has separate patches for the qobject and the json-parser
>> change.
>> 
>> We can pick one, of we can combine the best of both into a new
>> mini-series.  Preferences?
>
> I'll tackle a new mini-series with the best of both (I like your idea of
> reusing the same object across all uses, instead of creating a new one
> each time, particularly since it resulted in a smaller patch)

Sounds good!