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

[Markus Armbruster]

Peter Krempa <pkrempa at 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:
>> > On Fri, Nov 27, 2020 at 10:50:59 +0000, Daniel Berrange wrote:
>> > > Copying libvir-list for the deprecation warning.
>> > > 
>> > > 
>> > > On Mon, Nov 16, 2020 at 04:10:11PM +0300, Roman Bolshakov wrote:
>> > > > 'query-accel' QMP command should be used instead.
>> > > > 
>> > > > Signed-off-by: Roman Bolshakov <r.bolshakov at yadro.com>
>> > > > ---
>
> [...]
>
>> > We try hard to stay on top of such changes by using the new interface as
>> > soon as possible, but that is very hard if the replacement changes
>> > during the dev cycle.
>> > 
>> 
>> I see, thanks for the explanation! Perhaps I'll drop deprecation from
>> the series to avoid the issue.
>> 
>> Then as soon as libvirt gets support for queyring accels we might
>> consider deprecation again.
>
> I don't want to imply that it's entirely necessary to postpone it, but
> in such cases the new API which was added to replace the old one needs
> to be considered a bit more strongly until the release.
>
> The main reason for this is that libvirt has tests whether it uses any
> deprecated interface. If anything is marked as deprecated and our tests
> flag it, we add an override. Usually the override is added in the same
> patchset which actually implements the new approach.
>
> We obviously can add an override and then wait for the supported
> interface, but once the override is added there's nothing to remind us
> later on, so I generally like to have everything in one series.
>
> 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.

Here's an idea.  Keep a list of things to deprecate in the repository.
Instead of deprecating right away, we add to the list.  When soft freeze
comes, we go through the list and decide: either deprecate now (and
delete from the list), or postpone deprecation to the next release (and
keep it on the list).

Would that work for libvirt?

There's still a risk of us forgetting about the list.  Perhaps keeping a
reminder on the Planning/x.y wiki page could help.  Peter (Maydell), do
you have a check list for the various milestones?