All, This is another issue that we need to come to a consensus on (and I think we can do lazy consensus if required here) prior to 4.0 being released.
We've variously been discussing how to best provide binary artifacts from the 4.0 release. Knowing that we are purely discussing convenience builds for users, and that ASF releases are source only, I'd like to propose the following approach. I propose that the project only publishes source tarballs to the ASF mirrors, and that we rely on the community at large to publish binary build artifacts. Wido has volunteered to host deb and rpm repos containing packages built from the source, and I know that (over time) we will see the actual distributions put cloudstack packages together. I would imagine (and am not speaking for Wido), that we could work with Wido to ensure that his hosted repos have the latest release in them. We would then be in a position where it's OK if a specific distro packaging community is a version or two behind the ASF releases. That scenario would allow us to point users that want the very latest release to the custom repo, but folks that want official distro packages can simply use the version being provided by their OS's packaging system. For the convenience of the community, I'd further propose that we provide a set of links to these community repos on our download page (including appropriate verbiage about the URLs not representing official ASF release artifacts). This would also include instructions for how to setup a RHEL/CentOS/Ubuntu system to pull from Wido's hosted repos. As for QA teams involved in the testing of ASF releases, I believe that we should continue to use jenkins.c.o (with Citrix's agreement and continued support) as the source for downloading packages for testing. This is because it can do it for us on a nightly schedule. There is one optional part of this proposal: we include a tarball of cloudstack jar files on the ASF mirrors. Although, I'm just not sure what value that provides to the community. Thoughts? -chip
