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.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.

The CloudStack maintainers bear several responsibilities

  • Review, and potentially acceptance, of code changes from the community. Contributors and maintainers share responsibility for testing that new contributions work and do not break the application, and that the code changes are of high quality.
  • Mentorship of non-maintainers. Another role of the maintainer is to mentor non-maintainers into productive, recurring contributors or maintainers in the future.

While maintainers may develop and contribute code changes to CloudStack, more inherent in their role is that they act as a nurturing interface between the CloudStack community and the source tree.

It is important to note that maintainers are not so much granted authority as they are given ownership. Summed up, a maintainers role is to make their module shine, and to foster community growth around their module and CloudStack in general.

CloudStack Code Maintainers

Maintainer Requirements

CloudStack maintainers are skilled developers (or document writers) who have significant experience developing (or documenting) CloudStack. These individuals are familiar with the CloudStack coding standards, and are capable reviewers of code submissions.

Maintainer Scope

Each CloudStack maintainer has a specific module for which they are responsible and is to be their primary focus. They are intimately familiar with the module they are responsible for, act as the primary point of code review for code change submissions to the module, and interact with other members of the community on development topics related to the module and it's functionality. In general, maintainers only have commit rights on the module for which they are responsible.

Proven Maintainers

A select group of maintainers who have a history of successful contributions across multiple modules belong to a "Proven Maintainers" group. Proven Maintainers have commit rights for the whole source tree. The intention of this is not to provide access for working on more modules, but to allow a Proven Maintainer to help out in the event that another module's maintainer is unable to perform his or her duties. Proven Maintainers are still primarily responsible for the module for which they are the maintainer.

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

 


Code Testing and Code Quality

Besides reviewing code change submissions for logic and coding standard practices, maintainers are expected to test submissions to a reasonable level to ensure that inclusion of the change does not introduce defects into the source. If a code change to the source tree is found to break the build, the change must be reverted, with the maintainer to troubleshoot the issue.

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.

Development Workflow

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

Branching

The CloudStack Source tree is made up of several branches: The git 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 that branch. Any defects found in the release will be addressed in trunk, and released in a future release of the product.

When working on a new feature that requires significant changes or work from multiple contributors to CloudStack, a feature branch may be created for this development work. Once the changes are complete and are merged into trunk, the feature branch will be removed.

Individual contributors or groups of contributors are welcome to maintain their own private repository for development purposes. When code changes are ready to be submitted to CloudStack for inclusion in the public project, patches or git pull requests can be sent to the CloudStack Development mailing list (see Patch Submission, below).

Patch Submission

Patches are how the community submits code or documentation change requests to CloudStack maintainers. Patches are submitted under one of two conditions: either to fix a defect found in the CloudStack, or to add functionality to CloudStack.

When submitting a patch to address a defect, a bug report should be created which describes the defect, including the release version the defect was found in, and how to reproduce the defect. If the bug reporter intends to submit a patch, this should be noted in the bug report notes.

Similarly, a feature request should be documented before submitting a patch to provide new functionality.

The bug reporter/feature requester and the patch submitter do not need to be the same individual. Before performing work on a solution, a contributor should make a note on the bug/feature stating that they are working on it, presuming nobody has already made a similar statement. Once the contributor believes they have a working solution, a patch should be created using the git-format-patch command as described at CloudStack Development mailing list. If changes have been made across multiple modules, multiple patches should be created, one for each module. Patches should be sent to the CloudStack Development mailing list, along with a short description of what the patch is addressing, and any relevant bug IDs or feature request IDs.

Responsiveness to patch submissions

A maintainer will strive to respond to a patch submission within two weeks (14 calendar days) of initial submission. This is an important guideline for CloudStack; Community contributions are a main source of innovation and growth, and failure to respond to contributions may result in less submissions in the future. Repeated failure of this guideline may result in loss of maintainer status.

In the event where a maintainer fails to respond to a patch submission within a reasonable period of time, the contributor may raise the issue on the CloudStack Development mailing list.

Inability to contact submitter

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.

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.

Development releases

At this time, CloudStack does not feel the overhead required for Development releases is worthwhile - anybody interested in using a cutting-edge release can check out code from CloudStack's git repository.

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.

Appendix

References:

  • No labels