Peter Krempa <pkrempa@xxxxxxxxxx> writes: > On Fri, Jul 06, 2018 at 16:56:46 +0200, Kevin Wolf wrote: >> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben: >> > On Wed, 4 Jul 2018 17:14:02 +0100 >> > Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >> > >> > > On 4 July 2018 at 14:34, Kevin Wolf <kwolf@xxxxxxxxxx> wrote: >> > > > Essentially, what is important to me isn't getting these options dropped >> > > > exactly in 3.0, but not setting a bad precedence that deprecation isn't >> > > > actually worth anything. We may easily end up with this deprecation >> > > > process: >> > > > >> > > > depreate a feature >> > > > release QEMU version n + 1 >> > > > release QEMU version n + 2 >> > > > remove the feature >> > > > while libvirt hasn't removed use of the feature: >> > > > # ...and why should it when everything is still working? >> > > > reinstate the feature >> > > > release QEMU version n + x >> > > > remove the feature >> > > >> > > My take on the deprecation policy essentially is that it gives >> > > us a *minimum* bar for how soon we can drop something. We >> > > shouldn't be using it as an "always target this speed for >> > > dropping something" -- we ought to be pragmatic. We can >> > > drop stuff that's unused quickly, but should be slower >> > > for things that still have major users (or reconsider >> > > the deprecation entirely, potentially). There should be >> > > a balance between making our work as developers easier and >> > > inconveniencing our users. >> > >> > What about the following? >> > >> > - put a feature on the "normal" deprecation list to remove after two >> > releases >> > Case (a): nobody complains, either within the deprecation period or >> > when it is finally removed >> > -> all is good >> > Case (b): the feature turns out to be widely used, and/or it turns out >> > that it offers value that currently can't be offered easily in another >> > way >> > -> remove from deprecation list; this obviously needs more thinking >> > Case (c): the feature is used, the users are willing to move away from >> > it, but they need a bit more time >> > -> put it on a "deprecation watchlist", listing the users we are >> > waiting for, and then remove after all are done (no +2) >> > >> > That way, we can still easily remove old cruft (case (a)), but still >> > accommodate cases like this (case (c)). The obvious drawback is that >> > we'd need someone to curate the deprecation watchlist, to poke the >> > users we're waiting for, and probably remove anyway after some time if >> > they don't get their act together. >> >> The problem is that things are only starting to move after two releases >> have passed. The original idea was to already use that time. If we don't >> use it, then waiting for two releases is pointless and we can just >> directly let things go to a deprecation watchlist. >> >> Maybe we can just use the existing wiki page: >> >> https://wiki.qemu.org/index.php/Features/LegacyRemoval >> >> And add a column for whether libvirt is ready? Of course, that only >> makes sense if libvirt people make use of and contribute to this page. > > This should not be a problem, but I think we need some active > encouraging/prodding to remove deprecated stuff. Otherwise we might miss > the news. In addition to actively pulling libvirt developers into review of deprecation patches, we should pursue the idea to optionally let QEMU fail on use of deprecated features, then have libvirt run its test suite that way. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
