cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: CloudStack 4.0 release plan
Date Thu, 09 Aug 2012 11:48:47 GMT
Wow each of these could be its own email thread.

> So we're < 3 days away from the proposed release candidate being cut.
> I'm not sure about other's opinion right now, but I think that we
> might have been overly optimistic in the target dates.  The licensing
> issues alone are going to take longer than the time remaining.
> Watching the general@i.a.o list, I don't think we're going to be able
> to do an "official" ASF incubator release without solving these
> issues.
> I think we have three major areas to focus on:
> 1 - Source code licensing - We're moving along here, and *might* be
> able to make it by Friday, with the big caveat that there are
> outstanding questions about some license changes from upstream
> projects (ex: Xen).

So looking at the repo as a whole, there are still a lot of issues I
fear that need to be cleaned up. We are making good progress.

> 2 - Licensing for binaries - We have to resolve the build process
> question (continue down David's ant path, switch to maven, etc...).

I received zero pushback on my ant path, so I am planning on moving
forward with that, with the understanding that it's a stopgap that
needs to be fixed. Ivy, Maven, Gradle, etc are still on the table.
Changing build tools at this point in the cycle strikes me as
ill-advised. Especially when we move from plenty of folks knowing ant
to very few knowing maven/ivy/gradle.

> We also have to deal with the binary files that we would *like* to
> include, but are covered by Category X licenses.  We aren't going to
> be able to distribute them as binary packages, and therefore need to
> modify the build process / write up the instructions for how to
> optionally include them in a build.

Agreed. This is a non-trivial amount of work.

> 3 - System VMs - We're going to need to finalize a strategy here.  My
> interpretation is that we're not going to be able to distribute the
> system VMs as an ASF project.

So as noted in my OSCON notes (I think) this didn't seem to be the
impression that I walked away with. The big issue is that anyone needs
to be able to recreate a systemvm, and our software needs to be able
to be recreatable.

> 4 - Citrix feature development - Although we technically agreed that
> features would only make it in if they were ready, are the Citrix
> teams at a point where the features under development are considered
> to be of enough quality to be part of the release.  That also assumes
> that the contribution process was agreed to, and can be executed in
> time.

We are looking at time-based not feature-based releases, so this
doesn't bother me terribly. There is always the next release, and I'd
prefer us to not get in the habit of slipping dates to allow a feature
to make it in.

> 5 - Docs - We need to get documentation sorted out on a number of
> fronts: new feature docs, documentation build process issues and we
> will need to get our ASF website ready to host the release itself.
> That last point is also tied to licensing, since it's a requirement
> that system dependencies are documented somewhere like our project's
> website.

This is two separate masses of work.
The first is:
Docs: Since they are effectively code in the repo, having a code
freeze with a gatekeeper seems a bit pointless if they aren't also
ready to freeze. They are also nowhere near ready. We have
documentation about how to install from binaries (that might possible
change as well) We have no instructions in our documentation for
building from source, a list of dependencies, etc.

Website: Our project website (
needs lots of love. Joe has been working on this a bit. I don't think
this is a blocker for freeze, but as you denote it is for release.

> Should we consider mapping these activities to new timelines, and then
> reset the community's target dates appropriately?  Thoughts?
> -chip

View raw message