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(a)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.