apache/cloudstack
1
0
Fork 0
mirror of https://github.com/apache/cloudstack.git synced 2025-10-26 08:42:29 +01:00
Code Issues Packages Projects Releases Wiki Activity

updated contributin.md

Browse Source 
As this is the doc that is showed while creating a pull request, updated it with information from release principles wiki.
This commit is contained in:
Rajani Karuturi 2016-08-05 15:06:52 +05:30 committed by GitHub
parent 2875af7112
commit 4c387feebb
1 changed files with 24 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
CONTRIBUTING.md
View File

@ -3,10 +3,26 @@ Contributing to Apache CloudStack (ACS)
Summary Summary
------- -------
This document covers how to contribute to the ACS project. These instructions assume you have a GitHub.com account, so if you don't have one you will have to create one. Your proposed code changes will be published to your own fork of the ACS project and you will submit a Pull Request for your changes to be added. This document covers how to contribute to the ACS project. ACS uses github PRs to manage code contributions.
These instructions assume you have a GitHub.com account, so if you don't have one you will have to create one. Your proposed code changes will be published to your own fork of the ACS project and you will submit a Pull Request for your changes to be added.
_Lets get started!!!_ _Lets get started!!!_
Bug fixes
---------
It's very important that we can easily track bug fix commits, so their hashes should remain the same in all branches.
Therefore, a pull request (PR) that fixes a bug, should be sent against a release branch.
This can be either the "current release" or the "previous release", depending on which ones are maintained.
Since the goal is a stable master, bug fixes should be "merged forward" to the next branch in order: "previous release" -> "current release" -> master (in other words: old to new)
Developing new features
-----------------------
Development should be done in a feature branch, branched off of master.
Send a PR(steps below) to get it into master (2x LGTM applies).
PR will only be merged when master is open, will be held otherwise until master is open again.
No back porting / cherry-picking features to existing branches!
Fork the code Fork the code
------------- -------------
@ -30,6 +46,7 @@ $ git rebase upstream/master
Making changes Making changes
-------------- --------------
It is important that you create a new branch to make changes on and that you do not change the `master` branch (other than to rebase in changes from `upstream/master`). In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch will be created on your local repository and will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for the changes to be added to the ACS project. It is important that you create a new branch to make changes on and that you do not change the `master` branch (other than to rebase in changes from `upstream/master`). In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch will be created on your local repository and will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for the changes to be added to the ACS project.
It is best practice to create a new branch each time you want to contribute to the project and only track the changes for that pull request in this branch. It is best practice to create a new branch each time you want to contribute to the project and only track the changes for that pull request in this branch.
@ -72,6 +89,8 @@ Make a GitHub Pull Request to contribute your changes
When you are happy with your changes and you are ready to contribute them, you will create a Pull Request on GitHub to do so. This is done by pushing your local changes to your forked repository (default remote name is `origin`) and then initiating a pull request on GitHub. When you are happy with your changes and you are ready to contribute them, you will create a Pull Request on GitHub to do so. This is done by pushing your local changes to your forked repository (default remote name is `origin`) and then initiating a pull request on GitHub.
Please include JIRA id, detailed information about the bug/feature, what all tests are executed, how the reviewer can test this feature etc. Incase of UI PRs, a screenshot is preferred.
> **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/master` _before_ you do this. > **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/master` _before_ you do this.
``` bash ``` bash
@ -105,3 +124,7 @@ $ git checkout master
$ git branch -D feature_x $ git branch -D feature_x
$ git push origin :feature_x $ git push origin :feature_x
``` ```
Release Principles
------------------
Detailed information about ACS release principles is available at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up