On Fri, Sep 11, 2015 at 12:27 PM, Joe Brockmeier jzb@redhat.com wrote:
On 09/11/2015 12:59 PM, Adam Miller wrote:
On Fri, Sep 11, 2015 at 10:59 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Sep 10, 2015 at 01:02:10PM -0400, Matthew Miller wrote:
- Vagrant boxes:
- same tunir-based test suite in VM environemnt
Followup! Kushal points out that we are testing the KVM vagrant images in this way, but not testing VirtualBox. (Because we don't have VirtualBox in Fedora or EPEL, because out-of-tree kernel modules.). Like the qcow2->ec2 thing, these are the same bits as something that _is_ autotested, but run in a different environment. Unlike qcow2->ec2, we aren't even doing a boot test.
Things which could go wrong which I see are:
some VirtualBox-specific thing with booting an updated kernel or grub2 (for example, updated kernel missing some drivers or something that VirtualBox needs)
some corruption or something in the image conversion
These seem mostly unlikely, but far from impossible.
Since VirtualBox is the format the vast majority of Vagrant users will want, that's... kind of a big deal. *sigh* Options I can see here are:
A) Scramble to find some way to do the VirtualBox testing.
B) Don't publish the VirtualBox images.
C) Publish the VirtualBox images, but put them in a Penalty Box with extra warnings
Any other ideas? Preferences? B seems the most responsible, yet also the most sad. A would be highly unusual for our infrastructure. C could expose us to looking bad if support breaks and no one notices.
I'm pretty neutral on B or C. I don't really care and also don't think it should even remotely be a concern of ours. Not only do we not have testing for it but we don't even have the building blocks in place to work towards testing it. VirtualBox is bad and those who use it should feel bad.[0]
Damn, man. That's harsh and probably not a great way to bring people into the fold.
("should feel bad" I mean. I don't disagree on the merits of VB, it's not good.)
That wasn't fair, it was rude, and it certainly wasn't friendly. My apologies.
This is probably not a popular opinion and I'm fine with that, but we would have to install something that we very publicly speak out against in order to test this. I'm not yet ready to throw out Fedora's values for the sake of some OS X user's convenience but that's just me.
Which of the values would we be compromising here to test something with GPL'ed software? I realize that out of band modules aren't awesome, but I wasn't aware this was a project-level value [1]
This is a fair observation, I often intermix the technical guidelines and best practices with what are more so considered "Values" but the distinction is something I don't know that I care to debate. I'll just agree to disagree where necessary on this topic.
What I was referring to is: https://fedoraproject.org/wiki/Packaging:Guidelines#No_External_Kernel_Modul...
The "some OS X user" that we're trying to reach with VirtualBox-friendly images today is a potential Fedora desktop user tomorrow. I would totally agree we shouldn't compromise by using proprietary software, but using fully GPL'ed software to test something... that doesn't seem like a violation of Fedora values to me. (Note I'm differentiating between "values" and best practices/packaging guidelines/etc. here.)
I said it wasn't going to be a popular opinion and I'm fine with that. I also think that it's far stretch that we're going to convert OS X users to Fedora Workstation since the thing that we're trying to target here is effectively a headless cloud image but that's fine, I'll step off that one.
-AdamM
[1] https://fedoraproject.org/wiki/Overview#Our_Core_Values
-- Joe Brockmeier | Community Team, OSAS jzb@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct