How to interpret F18 Blocker criterion

[Adam Williamson]

On Wed, 2012-11-07 at 05:33 -0500, Kamil Paral wrote:
> > I don't think there's a conflict at all. All distros work hard to
> > dual
> > boot with Windows successfully because that's how you get people to
> > try
> > Linux: i.e., it's actually a key thing to have *in order to driver
> > our
> > philosophy*.
> > 
> > >  The current approach is that we don't care about problems with
> > > VirtualBox, with nvidia drivers, with just about _anything_ that is
> > > not included in Fedora. This test case doesn't really resonate with
> > > it.
> > 
> > I disagree, because there's a vital difference. The dual boot case is
> > about having Fedora - fully 'philosophy compliant' Fedora - working
> > _alongside_ a different proprietary operating system; a configuration
> > that's important to support for 'ideological' reasons as much as any
> > others (see above). What we don't support is proprietary components
> > *inside our own operating system*.
> 
> I also believe that the dual-boot support with Windows is important,
> should be thoroughly tested, and should be in our criteria. What
> annoys me is your reasoning being inconsistent with our past arguments
> about VirtualBox.
> 
> According to your explanation, VirtualBox support should be in a
> completely same position as dual-boot support with Windows. It does
> not change the Fedora platform, it just allows the project to run as a
> whole inside a virtualized environment. I believe it's even more
> important than dual-boot, because most of the newcomers don't install
> Fedora into dual-boot, they are scared and unsure about what might
> happen. They try it first in a VM, and #1 is usually VirtualBox. I
> come across that in all my Fedora presentations, I even _recommend_
> people to use VirtualBox prior to installing Fedora into dual-boot!
> 
> Yet, we don't give a damn about VirtualBox support. It's not in our
> criteria. We don't care much about its issues. We care a bit, but not
> much. Even though it's even open-source. (And it's very hard to find
> reasons why it's not included in Fedora, except for a single sentence
> here [1]).
> 
> I understand there are issues that we can't fix, because VirtualBox
> itself would have to be modified, and it's not under our direct
> control. But there are many issues that we can fix, like bugs in
> cirrus driver etc. And still we keep telling people "we don't support
> VirtualBox, this is not a blocker", even when it's a showstopper and
> we could fix it if we wanted.
> 
> So if the philosophy should really be interpreted as you say, I still
> find inconsistencies in our approach. Not with Windows support being
> superfluous, but with other components being missing.

VBox isn't unsupported for philosophy reasons exactly, but more for
technical reasons.

The main reason it's not packaged for Fedora is that it requires
out-of-tree kernel modules. There appears to be little interest on
either side for getting these upstreamed. Fedora does not accept
out-of-tree kernel modules.

I actually agree that your argument for supporting install as a VBox
*guest* makes a lot of sense, really, it's a pretty common use case.
It's probably true that we've applied the 'we don't support VBox' mantra
too easily to the VBox guest case, where it doesn't entirely apply. It's
more about using Fedora as a VBox *host*. I wouldn't be opposed to
proposals to test or even block on the VBox guest case, as it is a
common case. Though we'd need to consider the problem where it breaks
because of something in upstream VBox, which we can't control; that
might be a deal-breaker for making it a blocker.

The other side of the 'VBox isn't supported' argument, btw, is a very
pragmatic one: all the virtualization and kernel coders I've ever
happened to discuss it with seem to be in agreement that, technically
speaking, VBox is a pile of shit. There are reasons small-scale virt
users - i.e. desktop users who use virt on a single box for testing and
playing with new OSes - like it; it has a good UI for that use, and it
has some features the Fedora stack doesn't yet, notably 3D passthrough.
But looking at it in design and code quality terms, there appears to be
a strong consensus among Fedora devs that it's terrible code which has
fundamental problems that make them unwilling to commit too strongly to
'supporting' it. I don't know the details of this argument, though.
Maybe someone following this thread does.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net