7. [Source Code Patches](#contributing-patches-source-code)
8. [Documentation Patches](#contributing-patches-documentation)
9. [Contribute CheckCommand Definitions](#contributing-patches-itl-checkcommands)
+10. [Review](#contributing-review)
## <a id="contributing-intro"></a> Introduction
Please consider our [roadmap](https://github.com/Icinga/icinga2/milestones) and
[open issues](https://github.com/icinga/icinga2/issues) when you start contributing
to the project.
+Issues labeled with [help wanted](https://github.com/Icinga/icinga2/labels/help%20wanted) or
+[good first issue](https://github.com/Icinga/icinga2/labels/good%20first%20issue) will
+help you get started more easily.
Before starting your work on Icinga 2, you should [fork the project](https://help.github.com/articles/fork-a-repo/)
to your GitHub account. This allows you to freely experiment with your changes.
Choosing a proper name for a branch helps us identify its purpose and possibly
find an associated bug or feature.
-Generally a branch name should include a topic such as `fix` or `feature` followed
+Generally a branch name should include a topic such as `bugfix` or `feature` followed
by a description and an issue number if applicable. Branches should have only changes
relevant to a specific issue.
```
-git checkout -b fix/service-template-typo-1234
+git checkout -b bugfix/service-template-typo-1234
git checkout -b feature/config-handling-1235
```
## <a id="contributing-pull-requests"></a> Pull Requests
Once you've commited your changes, please update your local master
-branch and rebase your fix/feature branch against it before submitting a PR.
+branch and rebase your bugfix/feature branch against it before submitting a PR.
```
git checkout master
git pull upstream HEAD
-git checkout fix/notifications
+git checkout bugfix/notifications
git rebase master
```
New branch:
```
-git push --set-upstream origin fix/notifications
+git push --set-upstream origin bugfix/notifications
```
Existing branch:
```
-git push -f origin fix/notifications
+git push -f origin bugfix/notifications
```
You can now either use the [hub](https://hub.github.com) CLI tool to create a PR, or nagivate
Then change to your working branch and start rebasing it against master:
```
-git checkout fix/notifications
+git checkout bugfix/notifications
git rebase master
```
Once succeeded ensure to push your changed history remotely.
```
-git push -f origin fix/notifications
+git push -f origin bugfix/notifications
```
If you fear to break things, do the rebase in a backup branch first and later replace your current branch.
```
-git checkout fix/notifications
-git checkout -b fix/notifications-rebase
+git checkout bugfix/notifications
+git checkout -b bugfix/notifications-rebase
git rebase master
-git branch -D fix/notifications
-git checkout -b fix/notifications
+git branch -D bugfix/notifications
+git checkout -b bugfix/notifications
-git push -f origin fix/notifications
+git push -f origin bugfix/notifications
```
### <a id="contributing-squash"></a> Squash Commits
Save and let rebase to its job. Then force push the changes to the remote origin.
```
-git push -f origin fix/notifications
+git push -f origin bugfix/notifications
```
Basic unit test coverage is provided by running `make test` during package builds.
Read the [INSTALL.md](INSTALL.md) file for more information about development builds.
-Snapshot packages from the laster development branch are available inside the
+Snapshot packages from the latest development branch are available inside the
[package repository](https://packages.icinga.com).
You can help test-drive the latest Icinga 2 snapshot packages inside the
Icinga 2 is written in C++ and uses the Boost libraries. We are also using the C++11 standard where applicable (please
note the minimum required compiler versions in the [INSTALL.md](INSTALL.md) file.
-Icinga 2 can be built on Linux/Unix and Windows clients. In order to develop patches for Icinga 2,
+Icinga 2 can be built on Linux/Unix nodes and Windows clients. In order to develop patches for Icinga 2,
you should prepare your own local build environment and know how to work with C++.
More tips:
-* Requirements and source code installation is explained inside the [INSTALL.md](INSTALL.md) file.
+* Requirements and source code installation for Linux/Unix is explained inside the [INSTALL.md](INSTALL.md) file.
* Debug requirements and GDB instructions can be found in the [documentation](https://github.com/Icinga/icinga2/blob/master/doc/20-development.md).
-* If you are planning to debug a Windows client, setup a Windows environment with [Visual Studio](https://www.visualstudio.com/vs/community/). An example can be found in [this blogpost](https://blog.netways.de/2015/08/24/developing-icinga-2-on-windows-10-using-visual-studio-2015/).
+* If you are planning to develop and debug the Windows client, setup a Windows environment with [Visual Studio](https://www.visualstudio.com/vs/community/). An example can be found in [this blogpost](https://blog.netways.de/2015/08/24/developing-icinga-2-on-windows-10-using-visual-studio-2015/).
## <a id="contributing-patches-documentation"></a> Documentation Patches
updates can be found [here](CONTRIBUTING.md#contributing-documentation).
```
-vim doc/7-icinga-template-library.md
+vim doc/10-icinga-template-library.md
```
The CheckCommand documentation should be located in the same chapter
In case developers ask for changes during review, please add them
to the branch and push those changes.
+## <a id="contributing-review"></a> Review
+
+### <a id="contributing-pr-review"></a> Pull Request Review
+
+This is only important for developers who will review pull requests. If you want to join
+the development team, kindly contact us.
+
+- Ensure that the style guide applies.
+- Verify that the patch fixes a problem or linked issue, if any.
+- Discuss new features with team members.
+- Test the patch in your local dev environment.
+
+If there are changes required, kindly ask for an updated patch.
+
+Once the review is completed, merge the PR via GitHub.
+
+#### <a id="contributing-pr-review-fixes"></a> Pull Request Review Fixes
+
+In order to amend the commit message, fix conflicts or add missing changes, you can
+add your changes to the PR.
+
+A PR is just a pointer to a different Git repository and branch.
+By default, pull requests allow to push into the repository of the PR creator.
+
+Example for [#4956](https://github.com/Icinga/icinga2/pull/4956):
+
+At the bottom it says "Add more commits by pushing to the bugfix/persistent-comments-are-not-persistent branch on TheFlyingCorpse/icinga2."
+
+First off, add the remote repository as additional origin and fetch its content:
+
+```
+git remote add theflyingcorpse https://github.com/TheFlyingCorpse/icinga2
+git fetch --all
+```
+
+Checkout the mentioned remote branch into a local branch (Note: `theflyingcorpse` is the name of the remote):
+
+```
+git checkout theflyingcorpse/bugfix/persistent-comments-are-not-persistent -b bugfix/persistent-comments-are-not-persistent
+```
+
+Rebase, amend, squash or add your own commits on top.
+
+Once you are satisfied, push the changes to the remote `theflyingcorpse` and its branch `bugfix/persistent-comments-are-not-persistent`.
+The syntax here is `git push <remote> <localbranch>:<remotebranch>`.
+
+```
+git push theflyingcorpse bugfix/persistent-comments-are-not-persistent:bugfix/persistent-comments-are-not-persistent
+```
+
+In case you've changed the commit history (rebase, amend, squash), you'll need to force push. Be careful, this can't be reverted!
+
+```
+git push -f theflyingcorpse bugfix/persistent-comments-are-not-persistent:bugfix/persistent-comments-are-not-persistent
+```
projects / icinga2 / blobdiff