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 (http://incubator.apache.org/cloudstack/) 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
