On Nov 7, 2012, at 11:33 AM, Kamil Paral <kpa...@redhat.com> wrote: > > 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.
I think it's a big missing piece of the puzzle for overall reducing barrier to entry problems for trying out Fedora. I actually don't understand the RHEL angle on this missing piece either. What is the use case of installing RHEL along side Windows? Really, enterprise users do this? They share a single disk with one bootloader/manager taking over another? Seems risky to me. I'd think best practices would be, at best, separate OS's on separate drives, in the case of BIOS-MBR. For UEFI-GPT it's… different. The lack of explicit VirtualBox support not only reduces the test footprint when there are problems, but I think anaconda is made a lot more complicated than it needs to be in order to support the dual-boot case JUST for Fedora? So yeah, again, what's the dual-boot use case in enterprise? > 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. I agree. I don't think Windows support can be considered superfluous to the point that a reasonable conversation can be had to dump it as a release criteria, prior to the decision to support VirtualBox explicitly. And even then dual-boot is probably part of Fedora's demand because the developers depend on natively booting both, even if there's little enterprise use case. But there is a developer *and* enterprise use case for supporting VirtualBox. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
