Peter Krempa <pkrempa@xxxxxxxxxx> 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@xxxxxxxxx> >> > > > --- > > [...] > >> > 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?
