> 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. I'm very glad that you see it this way. I'd like to codify it somehow, and attach a link to this conversation, so we don't have to remember it. But I understand this is a problematic criterion, it would have to be very carefully worded. Basically, it makes sense to block the release only for VirtualBox issues that 1) are showstoppers, they prevent VB usage in a very serious way 2) are bugs in our components (e.g. graphics drivers), we can fix them and we also want to fix them (it wouldn't be a VB-specific hack). I'm not sure we want to have a criterion like that. I'd rather have it written down in a "best-effort goals" document. Issues related to that document would be considered blockers only when they are extremely serious, otherwise they would be just NTH. We would use common sense and developer feedback when judging it. But that goes against our current policy "if it's not in the criteria, it's not a blocker". Any preferences how to deal with that? What I can do immediately is to create a new test case for VirtualBox. I'd mark it as optional for the time being. WDYT? -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
