On Fri, Nov 9, 2012 at 7:17 PM, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On Fri, 2012-11-09 at 16:14 -0500, Josh Boyer wrote: >> On Fri, Nov 9, 2012 at 3:49 PM, "Jóhann B. Guðmundsson" >> <johannbg@xxxxxxxxx> wrote: >> > On 11/09/2012 08:34 PM, Josh Boyer wrote: >> >> >> >> Maybe you're talking about running Fedora as a vbox or vmware guest on >> >> some other OS? >> > >> > >> > Yup those are the use cases I'm concern about as in users running other OS >> > and installing Fedora as an virtualzation guest in that OS. ( like Robyn >> > pointed out with Vbox as in "people who do dev-type work on macs" ) >> >> Eh. There's certainly bugs in those cases too, because people install >> the 'guest' drivers to share the host FS and such, or because the >> implementation of the hypervisor is just broken. So like I said, I'm >> not really thrilled about that case either. >> >> However, I will admit it is a more difficult case to call because at >> least they're trying to use Linux in some form. I just don't think, >> from a criteria perspective, that it's fair to compare it to dual boot. > > You might want to read back in the thread to a post from Kamil in > response to me. I think we have a plausible way to go here, where we > write a criterion which says something like 'There must be no issues in > the installed system which prevent it from running as a guest on a > VirtualBox host' (roughly - just the idea, not final wording). The point > would be to only require that _we don't screw anything up_, not to say > definitively that 'the release must work as a VBox guest', as we do for > KVM. That gives us a get-out clause in the case where VBox itself is > busted upstream, which we don't want to block for; so long as everything > on the Fedora side was in order we'd be okay. Figuring out if it's vbox (or vmware or whatever) can take quite a bit of time. If this were to happen, someone would really need to step up to drive it and own it. > That way we could have a test case for running Fedora as a VBox guest, > and we could run it as part as validation, and if we ran into problems > we'd figure out whether they were Fedora-side or VBox-side, and if they > were Fedora-side they'd be blockers, but if they were VBox-side they > wouldn't. > > Sensible? I'm not sold on it at all, but it's not completely insane. I'd rather see it more as a testcase we run but don't block on. If it works, excellent. If it doesn't, we don't spend any time on it until all of the other actual criteria are fixed. My concern on making it an official criteria is three-fold. 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... 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. 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. josh -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
