On 2012-11-10 9:36, Josh Boyer wrote:
1) It's making something Fedora does not build, provide, or have any
influence on part of our release process. Doubly so if you're going
down the "test it using Windows or OS X as a host" route. I'm
personally not thrilled at all about adding such dependencies as
criteria at the moment. I also think if you're running it using a
Linux host, then there are other options we already support that do
just fine...
As others have pointed out, this is really rather a matter of
perception. It's perfectly reasonable to consider a given virtualization
system as a hardware platform on which Fedora ought to be able to run -
just like any random box from Dell or HP, except that we know for a fact
that millions of each of these boxes has been 'sold'. We don't build or
provide laptops, either, after all. :)
I suggest that your use of the plural 'options' there is somewhat
optimistic. As things stand we nominally support two 'options' - KVM and
Xen. Both of these have significant limitations. Xen in itself is, let's
face it, not popular. Especially not popular for desktop virt. To a
rough approximation, no-one uses it for that. KVM does not work on
Windows hosts, which obviously shuts out a large chunk of our potential
user base. And again, to be blunt, it is not very popular for casual
desktop virt (by which I mean just enthusiast end users running
single-system virt to try out multiple OSes). By a weird coincidence, a
rather handy reference for this happened to appear just yesterday:
http://ask.slashdot.org/story/12/11/09/2226249/ask-slashdot-which-virtual-machine-software-for-a-beginner
There are several replies that are positive about KVM, which is great,
but the general consensus is that it's a 'second step' to be used for
big grown up purposes, once you've grasped the basics using VMware or
VBox. Whether we agree with that or not, that's the perception that's
out there: KVM's a great technology, but it's for expert server
virtualization use, not casual desktop virt use. Still, it is nice to
see how positive people generally are about it as a technology.
The KVM stack works well on Fedora / RHEL and (so I've heard)
reasonably well on Ubuntu. I don't know if it's widely used or supported
on other distributions, or even necessarily packaged for them. It
definitely is not an option on Windows or OS X.
2) The testing and validation takes time and people. We seem to have
problems coming up with both of those already. Debugging issues
takes
both of those, plus knowledge about both the HV in question and the
area
in Fedora that is having problems (which is often "kernel").
3) The more criteria we add, the longer checks take.
These are all true, of course, but equally, true of any proposal. It's
a balance we always must keep in mind.
Maybe we already have testcases that are run but are not criteria. I
honestly have no idea. If we do, I think that would be a better fit
than trying to put some kind of weight behind Fedora as a guest in
these cases.
We do, and that's a plausible outcome. But I think those pushing for a
stronger approach than this are making a decent case. It's at least
worth considering if our 'we don't care about VBox' stance may be
hurting more than we had thought, and considering making more of a
distinction between 'we don't care about using Fedora as a VBox host'
and 'we rather do care about making sure Fedora works as a VBox guest,
as best we can'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
