Skip to content

Commit 4c387fe

Browse files
karuturikaruturi
authored
updated contributin.md
As this is the doc that is showed while creating a pull request, updated it with information from release principles wiki.
1 parent 2875af7 commit 4c387fe

1 file changed

Lines changed: 24 additions & 1 deletion

File tree

‎CONTRIBUTING.md‎

Lines changed: 24 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,26 @@ Contributing to Apache CloudStack (ACS)
33

44
Summary
55
-------
6-
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.
6+
This document covers how to contribute to the ACS project. ACS uses github PRs to manage code contributions.
7+
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.
78

89
_Lets get started!!!_
910

11+
Bug fixes
12+
---------
13+
14+
It's very important that we can easily track bug fix commits, so their hashes should remain the same in all branches.
15+
Therefore, a pull request (PR) that fixes a bug, should be sent against a release branch.
16+
This can be either the "current release" or the "previous release", depending on which ones are maintained.
17+
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)
18+
19+
Developing new features
20+
-----------------------
21+
22+
Development should be done in a feature branch, branched off of master.
23+
Send a PR(steps below) to get it into master (2x LGTM applies).
24+
PR will only be merged when master is open, will be held otherwise until master is open again.
25+
No back porting / cherry-picking features to existing branches!
1026

1127
Fork the code
1228
-------------
@@ -30,6 +46,7 @@ $ git rebase upstream/master
3046
Making changes
3147
--------------
3248

49+
3350
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.
3451

3552
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
7289

7390
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.
7491

92+
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.
93+
7594
> **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/master` _before_ you do this.
7695
7796
``` bash
@@ -105,3 +124,7 @@ $ git checkout master
105124
$ git branch -D feature_x
106125
$ git push origin :feature_x
107126
```
127+
128+
Release Principles
129+
------------------
130+
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

0 commit comments

Comments
 (0)