On Mon, 09 Jul 2018 08:33:05 +0200 Markus Armbruster <armbru@xxxxxxxxxx> wrote: > Peter Maydell <peter.maydell@xxxxxxxxxx> writes: > > > On 6 July 2018 at 15:56, Kevin Wolf <kwolf@xxxxxxxxxx> wrote: > >> Am 06.07.2018 um 13:11 hat Cornelia Huck geschrieben: > >>> 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. > > > > Right, so clearly just "put a note in the documentation" isn't > > sufficient advertisement/prodding of things going away. > > Yes. Ideas on more forceful notification have been tossed around, we > just have to act on them. > > > (Also, two > > releases is pretty fast. Many of our users will be using distro > > packaged versions of QEMU which will lag further behind than > > bleeding-edge users. The system version of QEMU on my desktop > > machine is 2.5...) > > If you consume QEMU in a way that's impacted by the changes the > deprecation policy guards, you have two sane options: > > * Track upstream deprecation, either continuously, or at least right > after a QEMU release. Since 2.10, they're collected in qemu-doc > appendix "Deprecated features". Can we draw more attention to this in any way? Point it out prominently in the release notes? Send a list to known consumers (e.g. libvirt) on release time? > > * Batch that work before you switch QEMU versions. Make sure to > allocate enough time. > > If you consume only downstream versions of QEMU, and don't want to track > upstream, go ahead and pick the second option. It should do even if you > leap from 2.5 (December 2015) all the way to 3.0. If you are a direct user of QEMU, you really need to follow development more closely, or you won't be able to complain about removal of a useful feature until it has already been gone for some time. If you only use QEMU through libvirt, you should be fine as long as libvirt (and distro packagers) do not mess up. Do we have any idea about how many end users using libvirt or other tooling vs. QEMU directly? Of those not going via libvirt, are they more likely to follow development or use a distro package? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
