This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Version 0.1

Table of Contents

Preface

CloudStack is an open source project that lives and grows thanks to the hard work of a large number of contributors (of both source code and documentation). The code and documentation changes suggested by community members are taken by a subset of committers who have volunteered to maintain and nurture specific sections of the CloudStack project.

...

Current Maintainers Per Component

The following are the list of maintainers for the major components of CloudStack as volunteered by the community.

Component

Primary Maintainer

Secondary Maintainers

CloudStack API

Alena Prokharchyk

 

EC2 API

Prachi Damle

 

S3 API

Chiradeep Vittal

 

UI

Brian Federle

Jessica Wang

Storage/Volumes

Chiradeep Vittal

 

Networking

Sheng Yang

Alena Prokharchyk, Chiradeep Vittal, Murali Reddy

Deployment Planners/Allocators

Prachi Damle

Nitin Mehta

System VM/Virtual Router

Sheng Yang

 

Console Proxy

Kelven Yang

 

Snapshots

Anthony Xu

 

XenServer

Anthony Xu

Abhinandan Prateek

XCP

Abhinandan Prateek

 

KVM

Edison Su

 

VMWare

Kelven Yang

 

OVM

Frank Zhang

 

BareMetal

Frank Zhang

 

Authenticators/LDAP

Abhinandan Prateek

 

VM Sync/HA

Abhinandan Prateek

Anthony Xu

Usage

Kishan Kavala

 

Events

Kishan Kavala

 

Database and Upgrades

Kishan Kavala

 

Templates

Nitin Mehta

 

Capacities

Nitin Mehta

 

Netscaler

Murali Reddy

 

Simulator/Test Framework

Prasanna Santhanam

 

SRX

???

 

F5

???

 

Setup/Install

Frank Zhang

Wido den Hollander

Ubuntu Packaging

Wido den Hollander

 

Include Page
Current Maintainers Per Component
Current Maintainers Per Component

Code Testing and Code Quality

...

A suite of automated QA tools does not yet exist for CloudStack, but as a suite is created, maintainers are expected to test submissions against the suite before committing changes to CloudStack.

Voting

...

Development

...

The only time formal voting is required is for approving a formal release of CloudStack. This will be explained further in a separate document, but will require +3 binding votes within 72 hours.

Development Workflow

Details about CloudStack's git development workflow can be found at Git workflow in the brave new world

...

The CloudStack Source tree is made up of several branches: The git trunk source trunk, release branches, and feature branches.

The source trunk is the active main development tree for CloudStack . When a formal release is made, a branch will be created from trunk, and the release will be made from ("master"). Except for feature branches, this will always have the latest code.

Release branches represent code used to create a General Availability release. Approximately one month before the GA release, a branch from HEAD will be made, named after the version to be released (e.g. "release-4.0"). From within that branch, Release Candidate packages will be created and tested until the community feels the quality of the code is sufficient for a GA release. Each time a Release Candidate is made, that revision of the code will be tagged appropriately (e.g. "release-4.0RC1"). Once the GA release is made, no more changes will be applied to that branch. Any defects found in the after a GA release will be addressed in trunk, and released in a future release of the product.

...

In the case where somebody has stated they would work on the issue, and a significant period of time has passed without a patch submission, the maintainer should contact the individual to check for an update. If, after 30 days, the maintainer is unable to contact the submitter, the bug/feature should be released for others to submit patches against.

Release Workflow

CloudStack intends to produce stable "General Availability" ("GA") for public consumption three times per calendar year. Approximately one month before an intended release date, the CloudStack development community will begin preparing for the GA release by creating Release Candidate ("RC") releases

With the goal of a "general availability" release, Apache CloudStack will use the following version labels to notate progress towards a GA release. In the future, the project may add additional labels (such as "Beta") or further voting to ensure the quality of releases.

Keep in mind that both Release Candidate and General Availability releases require voting, as described in the Voting section below.

Release Candidates

Approximately one month before a GA release is to be made, the CloudStack development community will package and release a Release Candidate ("RC"). This package manifests the community's interest in creating a GA release with the featureset found in the branched code, and requests the community to perform testing and QA on the RC to find bugs and other issues which should be mitigated before the GA release. Each release will be named in a format similar to "apache-cloudstack-4.0.0.RC2-incubating-src.tar.gz"

During the "RC" cycle, an RC release will be made, and the community will QA and report bugs, and another RC candidate will be made in a period between 1-2 weeks after the last. This cycle will continue until the community feels the release is reaching the quality worthy of a GA label.

General Availability Releases

Once the community feels that the QA process has found and fixed issues to create a release that will be stable and usable by the general public, a GA release can be made. Each GA release will be named in a format similar to "apache-cloudstack-4.0.0-incubating-src.tar.gz"

Voting

For all CloudStack releases (RCs or GA), a formal VOTE binding upon Apache is required before release. The only time formal voting is required is for approving a formal release of CloudStack. While in incubation, CloudStack will need at least 3 positive votes from Apache Incubator PMC members. Details about this process can be found here.

The standard submission/review/commit life-cycle should exist without need to cast votes. In the event of a disagreement, either the maintainer or contributor may bring the issue to the attention of the CloudStack Development list.

Version Numbers

Apache CloudStack releases will have a version number in the format of major.minor.point.

Changes in the major version number represents very significant changes - major updates to the code base, moving the project to a new home, etc.

Changes in the minor version number represents "standard" GA releases.

Changes in the point version number represents fixes applied to the relative GA release.

How to Perform a Release

Note

This only includes a source code release right now. We need to evolve / edit when we get our binary build process sorted out.

Publishing Release Candidates

The following steps document the process of publishing an RC.

Assumptions:

  1. The community member has gpg installed locally, and has added their public key to the KEYS file in the project's source repo.
  2. The community member has commit rights on the CloudStack git repo.
  3. The community member has commit rights for the CloudStack svn repo (for updating the cloudstack website).
  4. The community member has commit rights for the https://dist.apache.org/repos/dist/dev/cloudstack svn repo.

CloudStack RC's are distributed via the ASF mirroring system, and are provided to the community via the http://cloudstack.apache.org/downloads.html page. In order to create the release candidate, you can follow the steps below to get it hosted within the ASF mirrors.

Steps:

Create (or identify) the release branch in git. Normally, we name release branches with the full x.y.z release number (but exclude the RCx portion that will be used during the release process). If the branch is being created, then ensure that it has been pushed to the ASF repo before moving on from here.

Run tools/build/build_asf.sh:

Code Block
# tools/build/build_asf.sh -h
usage: tools/build/build_asf.sh -v version [-b branch] [-s source dir] [-o output dir] [-t [-u]] [-h]
  -v sets the version
  -b sets the branch (defaults to 'master')
  -s sets the source directory (defaults to ~/incubator-cloudstack/)
  -o sets the output directory (defaults to ~/cs-asf-build/)
  -t tags the git repo with the version
     -u sets the certificate ID to sign the tag with (if not provided, the default key is attempted)
  -h

Example:

Code Block
# tools/build/build_asf.sh -v 4.0.0RC1 -b master -s ~/incubator-cloudstack -o ~/rc1 -t -u XXXXXXXX
Using version: 4.0.0RC1
Using source directory: /Users/apache.user/incubator-cloudstack
Using output directory: /Users/apache.user/rc1
Using branch: master
Tagging the branch with the version number, and signing the branch with certificate ID XXXXXXXX.

gpg: using PGP trust model
gpg: using subkey XXXXXXXX instead of primary key XXXXXXXX

You need a passphrase to unlock the secret key for
user: "Apache User <apache.user@apache.org>"
4096-bit RSA key, ID XXXXXXXX, created 2012-08-06 (main key ID XXXXXXXX)

gpg: writing to `cloudstack-source-4.0.0RC1.tar.gz.asc'
gpg: RSA/SHA1 signature from: "XXXXXXXX Apache User <apache.user@apache.org>"
gpg: using PGP trust model
gpg: using subkey XXXXXXXX instead of primary key XXXXXXXX

You need a passphrase to unlock the secret key for
user: "Apache User <apache.user@apache.org>"
gpg: using subkey XXXXXXXX instead of primary key XXXXXXXX
4096-bit RSA key, ID XXXXXXXX, created 2012-08-06 (main key ID XXXXXXXX)

gpg: writing to `cloudstack-source-4.0.0RC1.zip.asc'
gpg: RSA/SHA1 signature from: "XXXXXXXX Apache User <apache.user@apache.org>"
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
gpg: armor header:
Comment: GPGTools - http://gpgtools.org
gpg: armor header:
gpg: Signature made Tue Sep  4 15:48:44 2012 EDT using RSA key ID XXXXXXXX
gpg: using subkey XXXXXXXX instead of primary key XXXXXXXX
gpg: using PGP trust model
gpg: Good signature from "Apache User <apache.user@apache.org>"
gpg: binary signature, digest algorithm SHA1
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
gpg: armor header:
Comment: GPGTools - http://gpgtools.org
gpg: armor header:
gpg: Signature made Tue Sep  4 15:48:46 2012 EDT using RSA key ID XXXXXXXX
gpg: using subkey XXXXXXXX instead of primary key XXXXXXXX
gpg: using PGP trust model
gpg: Good signature from "Apache User <apache.user@apache.org>"
gpg: binary signature, digest algorithm SHA1

You need a passphrase to unlock the secret key for
user: "Apache User <apache.user@apache.org>"
4096-bit RSA key, ID XXXXXXXX, created 2012-08-06 (main key ID XXXXXXXX)

During the script's run, you should be prompted to enter your pass-phrase for your key during the signing process.

The output directory specified (or defaulted) should now contain the following files:

Code Block
KEYS
cloudstack-source-4.0.0RC1.tar.gz
cloudstack-source-4.0.0RC1.tar.gz.asc
cloudstack-source-4.0.0RC1.tar.gz.md5
cloudstack-source-4.0.0RC1.tar.gz.sha
cloudstack-source-4.0.0RC1.zip
cloudstack-source-4.0.0RC1.zip.asc
cloudstack-source-4.0.0RC1.zip.md5
cloudstack-source-4.0.0RC1.zip.sha

You should verify the archive contents now, to confirm that they have packaged correctly. Once verified, it's time to push them into the ASF dist repo:

Check out the https://dist.apache.org/repos/dist/dev/cloudstack folder. Copy these files to that folder, issue an svn add, and svn commit with a sane message about the Release Candidate number.

Note

We need to figure out the RC archiving policy.

Once the commit completes (it may take a good bit of time, due to the size of the CloudStack source tree), you now have to wait for the mirrors to catch up (24 hours).

After the mirrors have caught up, the cloudstack site needs to be edited. Check out https://svn.apache.org/repos/asf/cloudstack/site/trunk/content/ and edit the downloads.mdtext file's RC section to point to the new RC version.

Commit that site edit, and review it here: http://cloudstack.staging.apache.org/downloads.html

Once satisfied, use the ASF CMS to publish that page (from here: https://cms.apache.org/cloudstack/publish?diff=1 )

Once completed, let the cloudstack-dev@i.a.o list know!

Publishing Approved Releases

TBD

Appendix

References: