|
From: | Andreas Färber |
Subject: | Re: [Qemu-devel] Unmaintained QEMU builds |
Date: | Sun, 5 Sep 2010 17:01:53 +0200 |
Am 05.09.2010 um 13:19 schrieb Avi Kivity:
On 09/04/2010 04:56 PM, Andreas Färber wrote:Maybe it's time to rethink the relation between QEMU and its frontends / management tools? If we want to compete with the commercial products (sic), we might agree on some "official" frontend per GUI-centric platform, with a Git-based repository (like qemu-kvm.git) and synchronized releases that may call themselves "QEMU", linked from qemu.org, rather than having a variety of (outdated) Q* frontends per platform of which most are nothing more than a configuration window to spawn the regular qemu[- system-x86_64].There is also virt-manager which is quite rich at this time.
Seems I didn't get the point across too well: Standard users on Windows-PC and Mac expect a solution to their needs, not a forest of well-designed libraries and tools with .tgz downloads. QEMU has no such product identity, and there's no prominent binary download link for Win/Mac on the qemu.org frontpage.
virt-manager is neither prominently advertised there either, nor does it have a Windows download. (Fwiw while it's certainly nice on Linux and to some limited degree on Solaris (ancient fork apparently), I wouldn't exactly describe the virt-install versions I've seen as "rich"... and setting up the VM is somewhat a prerequisite to using virt-manager's indeed nice features. Fedora's default security policies on top don't exactly make it easy to try out .isos or downloaded disk images with virt-manager, its German translation had a severe contentual error in the VM's menu and a felt 80% of the BRC bug reports get ignored and closed by a bot anyway, but that's another topic.) But sure, on Linux there's a plethora of simplistic Q* frontends, too. (n.b., virt-manager didn't match that regex ;)
Choice and diversity isn't wrong per se, just the comparison of the available options on the two given platforms has shown not to make QEMU a common choice. Whining about lack of bugfix contributions is unlikely going to change that imo.
As a baby step, is there any chance of publishing an automatic nightly Windows (cross-)build as a .zip file on qemu.org? That might give more users a chance of detecting runtime faults during the development cycle.
Andreas
Currently what QEMU can point with is richer machine and hardware emulation and its license; if we want more users than that, we'll need to deliver what users usually want the most - stability, performance and ease of use... and good marketing.They may as well be merged into qemu.git directly, so long as: - the GUI has its own maintainer- the prepackaged GUI doesn't get access to internal APIs, compared to external tools-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |