Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

This is a proposed way of working, under discussion on the mailing list. See http://markmail.org/message/xoyjw2sduenlytwm

Commit to master through PR only was decided on here: http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/62223

Summary

Apache CloudStack is a broad and encompassing project covering many areas that require in-depth technical knowledge.  As such, it is not possible for one person to know and/or test all components of CloudStack in depth.  Miscommunications and misunderstandings between developers can lead to poor quality in CloudStack's code and cause community to deliver a unstable release.  Knowledge lost from one release to the next can cause regressions in the current release.  This page details the development process the CloudStack community must follow in order to ensure the community delivers high quality releases.  This page is a must read for all developers and testers.

...

The process is very simple.

  1. Create a branch for your code or the patch you're helping to submit (Use github Fork the code on Github and send a pull request (even if you are not yet a committer)
  2. Assign the JIRA issue to yourself, change the status to "In Progress", add the branch information into the issue.
  3. When the work is completed, do the following things.
    1. Arrange for a review with two colleagues.
    2. Send the pull request and then ask two colleagues to review and give their "LGTM".
    3. Testing will be done on your pull request, the Travis CI output will appear on the pull request.Use Jenkins to ask automation be run on your branch. (Steps below)
  4. Once review and automation are completed successfully, a committer will merge the branch to the release branch or master. 
  5. Once the merge is completed, change the status of the issue to "Resolved."

...

  • It is up to the developer to find the right people to review his/her code changes.  
  • It is within the reviewer's right to decide whether they are the appropriate reviewer for a code change.  
  • If they are not or if the review requires technical expertise from others, the reviewer can either refer the developer to another reviewer or pull in another reviewer.

...