Re: [PATCH for-6.0 6/6] qapi: Deprecate 'query-kvm'

[Markus Armbruster <armbru@redhat.com>]

Peter Krempa <pkrempa@redhat.com> writes:

> On Fri, Nov 27, 2020 at 16:44:05 +0100, Markus Armbruster wrote:
>> Peter Krempa <pkrempa@redhat.com> writes:
>> 
>> > On Fri, Nov 27, 2020 at 14:45:12 +0300, Roman Bolshakov wrote:
>> >> On Fri, Nov 27, 2020 at 12:21:54PM +0100, Peter Krempa wrote:
>
>  [...]
>
>> > As you can see this has an issue when we have to add support for a
>> > unreleased interface, which may change during the dev cycle or plainly
>> > forget that something got deprecated as we've already added an override.
>> >
>> > This mainly comes from libvirt trying to keep on top of the changes so
>> > we refresh the QMP schema during qemu's dev cycle multiple times.
>> >
>> > Obviously the argument that we try to depend on unreleased functionality
>> > can be used, but that would be to detrement of progress IMO.
>> 
>> I understand your concerns.
>> 
>> We have a somewhat similar problem in QEMU: there's nothing to remind us
>> later on that the old interface still needs to be deprecated.
>
> Oh, yes. That's basically the same thing.
>
> The thing is that changes to the new interface are very rare, but very
> real. Since I don't really want to increase the burden for any normal
> scenario.
>
> I'd also very much like to keep libvirt pulling in snapshots of qemu's
> capabilities/qapi schema etc throughout the development cycle. It allows
> us to adapt faster and develop features simultaneously.
>
> This unfortunately undermines my own arguments partially as libvirt
> regularly develops features on top of unreleased qemu features so we are
> regularly risking very similar circumstances. The small but important
> difference though is, that releasing a broken feature is not as bad as
> breaking an existing feature.
>
> As a conclusion of the above I'd basically prefer a sort of gentleman's
> agreement, that new APIs become 'somewhat' stable at the moment the
> commit deprecating the old interface hits upstream.
>
> The 'somewhat'-stable API would mean that any changes to the new API
> should be consulted with libvirt so that we can either give a go-ahead
> that we didn't adapt yet, disable the adaptation until the changes can
> be done, or another compromise depending on what's the state.
>
> I know it's hard to enforce, but probably the cheapest in terms of
> drawbacks any other solution would be.

We can and should try.  

Can we flag problematic interface changes automatically?  Semantic
changes, no.  What about changes visible in query-qmp-schema?

> I'll probably keep notifying patchsets which implement and deprecate old
> api at the same time to keep in mind that we need to be kept in touch,
> but I really don't want to impose any kind of extra process to
> development on either side.

Thanks!