Marc-André Lureau <[email protected]> writes: > Hi > > On Thu, Oct 29, 2026 at 5:45 PM Markus Armbruster <[email protected]> wrote: >> >> Markus Armbruster <[email protected]> writes: >> >> > Marc-André Lureau <[email protected]> writes: >> > >> > [Possible improvement to the QAPI/QMP QOM introspection interface...] >> > >> >>> Thoughts? >> >> >> >> I like it overall. >> >> >> >> But this goes beyond the intended scope of the series. >> >> Blending/merging QOM type & QAPI type would warrant more design >> >> research. So covering child<> & link<> are out of scope of the current >> >> qom-qapi series. I think the addition of qapi-type shouldn't be >> >> incompatible with a future proposal, after all all properties should >> >> have some 'wire' type (link/child are paths). But we can drop it for >> >> now or just rename it x-qapi-type until we agree on the new >> >> introspection. >> >> >> >> my2c >> > >> > Adding @qapi-type with feature unstable means we don't have to worry >> > about the external interface now. One less hurdle for merging. I like >> > it. >> > >> > Whether changing the @type values is safe remains somewhat unclear. See >> > >> > Subject: Property types changed in this series (was: [PATCH v7 00/65] >> > Hi) >> > Date: Wed, 21 Oct 2026 18:29:40 +0200 >> > Message-ID: <[email protected]> >> >> We're about to miss the soft freeze. Not your fault; I've been awfully >> slow reviewing this. >> >> The series is quite big. If we can't get it merged, we'll have to >> rebase and update it. Not good. >> >> Here's a possible way forward: >> >> 1. We tweak this series to retain the existing @type values. >> >> As is, the series changes @type to the QAPI type where applicable. >> This is an improvement, and *probably* safe enough, but I'm reluctant >> to accept the risk this late in the development cycle. >> >> I can do the tweaking. It'll be mildly icky, but should go away >> fairly soon. > > Tbh, I don't think changing @type is going to hurt, and if it > effectively does, we still have the rc period or backports as > necessary.
I don't think the changed values are enough of an improvement to be worth the risk and the churn. Retaining the existing values turned out to be much less icky than I thought. >> 2. We mark @qapi-type unstable for now. > > yes Done. >> 3. Try hard to get it merged in time for 11.2. >> >> We can then improve on top at our leisure: >> >> * If we convince ourselves that changing @type values is worthwhile and >> safe enough, do so early in a development cycle. >> >> * Hunt down the remaining properties that don't use a QAPI type. >> >> * Explore more comprehensive improvements to QOM introspection. >> >> * Settle on a new QOM introspection interface, deprecate the old crap. > > I think we should flush the queue, because it's natural to stop > working on a "topic" when it reaches >50 pending patches. And it > prevents other people from joining the effort too. If it takes >6 > months to get 50 patches accepted, the QOM-QAPI dilemna is going to > stay for a long time :) Oh yes, we should flush the queue. This series took me waaaay too long. Series as big as this one take big chunks of uninterrupted time to process, and these are hard for me to come by. I should've gone "I do this series now whatever it takes, and screw everything else" much earlier. My sincere apologies.
