On 09/11/2015 12:59 PM, Adam Miller wrote:
> On Fri, Sep 11, 2015 at 10:59 AM, Matthew Miller
> <mattdm@xxxxxxxxxxxxxxxxx> 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.)
> 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].
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.)
[1] https://fedoraproject.org/wiki/Overview#Our_Core_Values
--
Joe Brockmeier | Community Team, OSAS
jzb@xxxxxxxxxx | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
