Table of Contents |
---|
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.
...
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
Include Page | ||||
---|---|---|---|---|
|
...
Ubuntu Packaging
...
Wido den Hollander
...
...
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.
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
...
Keep in mind that both Release Candidate and General Availability releases require voting, as described in the Voting Voting section below.
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-src-4.0.0.0RC1RC2-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.
...
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-src-4.0.0-incubating-src.tar.gz"
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.
...
CloudStack RC's are distributed via the ASF mirroring system, and are provided to the community via the http://incubatorcloudstack.apache.org/cloudstack/downloads.html page. In order to create the release candidate, you can follow the steps below to get it hosted within the ASF mirrors.
...
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:
.
Run tools/build/build_asf.sh:
Code Block |
---|
# tools/build/build_asf.sh -h |
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) |
...
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/incubator/cloudstack folder. Copy these files to that folder, issue an svn add, and svn commit with a sane message about the Release Candidate number.
...
After the mirrors have caught up, the cloudstack site needs to be edited. Check out https://svn.apache.org/repos/asf/incubator/cloudstack/site/trunk/content/cloudstack/ 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/cloudstack/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!
...