On Thu, Jul 26, 2012 at 10:46 AM, John Kinsella <j...@stratosec.co> wrote: > So basically for a good portion of CloudStack users, we're removing > functionality that they're currently using. > > Do we have any idea what percentage of CS users compile from source vs use > packaged versions? How many users of the packaged product will decide to > switch to a different platform where they don't have to jump through hoops to > get it to work? > > If we go this route, and some third party happens to be packaging CS builds > with kvm support enabled, would/could the Apache CloudStack download page > provide a link to that? > > I know this has been discussed from a legal/engineering POV, but I'm > envisioning some amount of teeth gnashing, just wondering the best way to > handle it…I don't want to see headlines "CloudStack removes support for KVM" > which is what the more dramatic will say. >
As Kevin noted, this is effectively just setting the default build to not build KVM (e.g. what is the build-all target right now) It appears, based on our conversations, that CloudStack can ship convenience binaries (see my comments below about releases) that have items that would be prohibited in releases. I.e., we could ask for an exception to ship convenience binaries of CloudStack with libvirt-java in place, or we could build the binaries with a dependency on libvirt-java - either would keep KVM support present for users. So the difference is what the ASF considers a release. Only source releases are 'releases' under the ASF's definition. Binary artifacts are merely built for the user's convenience. I also was concerned that there would be much wailing and gnashing of teeth, please see the discussion we had at OSCON, about this matter [0]. I am convinced that much of that drama can be avoided now - though, VMware-support might be an issue. [0] http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201207.mbox/%3CCAKprHVa5feNc1eZicahsqwPKdn6Uezeh_So%2BpRBQtyEDxC2nWw%40mail.gmail.com%3E