incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: CloudStack 4.0 release plan
Date Wed, 08 Aug 2012 20:56:47 GMT
On Mon, Jul 30, 2012 at 9:33 PM, Ewan Mellor <Ewan.Mellor@eu.citrix.com> wrote:
> Hi all,
>
> After my draft release plan last week, I've taken the feedback that I got (thanks for
that, everyone) and I think we're ready to commit to this plan now.
>
> The timescales are very tight, but that's the aim - get something out as soon as we can,
to make our first release as an Apache-incubated project.  I'll be keeping track of who's
doing what, so that we can keep on schedule.  Please let me know if there's anything that
comes up that might be a problem.
>
> I would like to highlight the issue of internationalization for this release.  At the
moment, we have no-one looking at the various translations in the tree, so the 4.0 release
will be English only, and we will follow up later with translation packs as and when they
are ready.  If someone wants to invest time in a translation immediately, then we would be
able to take them during our release-candidate phase.  Please volunteer if that is the case.
 The release-candidate phase won't be a complete UI freeze, so you may need to do a few translations
at the last minute, but the bulk of the job can be tackled right now.
>
> So the plan looks like this:
>
> Development phase: Now - Friday 10 August.
> Release branch opens: Monday 13 August.
> Stability and bugfix work: Monday 13-Friday 17 August.
> First release candidate build: Friday 17 August.
> Testing and subsequent release candidates: Monday 20 - Friday 31 August.
> Release: Tuesday 4 September (the day after Labor Day and the week after Linux Foundation's
CloudOpen).
>
> This is going to be a time-based release: we will take features if they are ready, but
we're not going to delay the release if they aren't.
>
>
> Other things that are happening:
>
> David Nalley, Pradeep Soundararajan, Chip Childers, and Edison Su are working on sorting
out our build dependencies, turning off things that depend on non-Apache SDKs (libvirt-java,
mysql-connector-java, NetApp, F5, and VMware SDKs).
> Alena Prokharchyk is preparing the VPC branch for merge.
> Vijay Venkatachalam, Pranav Saxena, Deepak Garg are preparing the autoscale branch for
merge.
> I'm getting automated testing stood up.
> Jessica Tomechak and Radhika Puthiyetath will be finalizing the documentation in a few
weeks.
>
>
> Cheers,
>
> Ewan.
>

Ewan,

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).

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

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.

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.

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.

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

-chip

Mime
View raw message