Re: [Qemu-devel] Unmaintained QEMU builds

[Andreas Färber]

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