From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbSIY-00087W-GZ for qemu-devel@nongnu.org; Fri, 06 Jul 2018 11:05:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbSIX-0002qF-7o for qemu-devel@nongnu.org; Fri, 06 Jul 2018 11:05:26 -0400 Date: Fri, 6 Jul 2018 16:05:15 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Message-ID: <20180706150515.GF28022@redhat.com> Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20180625114528.GL16514@angien.pipo.sk> <20180702080411.GA4299@localhost.localdomain> <60f6bf3c-6cad-c86f-01d7-8c376a6ccfe0@de.ibm.com> <20180703111949.GB24516@redhat.com> <20180703113229.GD3812@localhost.localdomain> <20180704150256.408d4a07.cohuck@redhat.com> <20180704133440.GE4334@localhost.localdomain> <20180706131103.4e713911.cohuck@redhat.com> <20180706145645.GB3939@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180706145645.GB3939@localhost.localdomain> Subject: Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Cornelia Huck , Peter Maydell , Boris Fiuczynski , Qemu-block , Libvirt , QEMU Developers , Christian Borntraeger , Peter Krempa On Fri, Jul 06, 2018 at 04:56:46PM +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 wrote: > > > > > On 4 July 2018 at 14:34, Kevin Wolf 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. FYI I checked the list of deprecated features, and aside from the drive ones, libvirt is impacted by the VNC TLS stuff, and the change to "target" in the query-cpus-fast QMP command. I've got bugs open against libvirt to address all of these Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|