qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] Options for 4.0


From: Peter Krempa
Subject: Re: [Qemu-block] Options for 4.0
Date: Tue, 2 Apr 2019 10:42:49 +0200
User-agent: Mutt/1.11.3 (2019-02-01)

On Tue, Apr 02, 2019 at 10:19:29 +0200, Kevin Wolf wrote:
> Am 01.04.2019 um 22:02 hat Markus Armbruster geschrieben:
> > Markus Armbruster <address@hidden> writes:

[...]

> > Given that the libvirt code isn't ready, why do we need this done and
> > declared stable in 4.0?  We're going to tag -rc2 tomorrow...
> 
> The next libvirt release will be long before the next QEMU release. If
> we don't have it in 4.0, enabling -blockdev will have to wait until the
> first libvirt release after the QEMU 4.1 release (so maybe September)
> and we'll still be stuck with -drive and unable to start deprecating it
> until then.
> 
> Also, we don't want to give Peter the excuse that the qemu code isn't
> ready. ;-)

It will not be an excuse. That's because we have plenty of 'prior art'
in adding version-based capabilities if everything else fails. I'm just
always unhappy when I see it.

In this instance I failed to speak up soon enough to get a better fix
ready. I could try to excuse myself, but I will not.

Just please don't drop the work that can be used to detect further
changes like this. It might come in handy sooner or later.

At this point I'd not change anything. I agree that last second fixes
have a big probability to be regretted later.

In the end it may end up being necessary to fix yet another thing for
blockdev or something else and we can at least prevent that from having
a version-based check.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]