qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
Date: Tue, 27 Jul 2010 10:26:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 07/26/2010 02:19 PM, Avi Kivity wrote:
[...]
>> Regardless, outside of Windows users qemu will mostly be consumed
>> via distribution branches, with different levels of backport
>> happiness.  We should recognize that and work with it, not against
>> it.
>
> And it's trivially easy for libvirt to deal with this.  They simply
> have to do: `cat /etc/redhat-release` or `cat /etc/suse-release` and
> adjust version logic accordingly.

It's always trivially easy for *another* project to do the work.

> It's an easy change for libvirt to make, and the problem goes away for
> the future.  If such a change was made, I'd be inclined to take a
> patch like this now to make up for the difference.
>
> But as I said, we've been accommodating libvirt's use of help for a
> long time now.  We shouldn't let perfect (omnipotent capabilities
> system) stand in the way of good (version/feature matrix).

We've declared our intention to provide a decent capability system (I
said decent, not perfect).  If I know anything about libvirt developers,
they'll *jump* at the chance to replace their existing code by a
capability system, because they consider their existing code messy and
brittle.

But now we tell them to replace it by a different method first, or else.
A method that is at least as messy & brittle in their judgement.  Which
is based on a few person-decades of experience trying various methods.
A method that is to be thrown out again when the capabilities system is
ready, i.e. about the time its inevitable wrinkles got ironed out.

Not going to happen.  All this little feud is going to accomplish is to
hurt users.

[...]



reply via email to

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