From 74d06bf04ee7cf7786d860ca147c404ee241cc20 Mon Sep 17 00:00:00 2001 From: Herasym Oleh Date: Mon, 1 Feb 2016 12:00:15 +0200 Subject: Add COMMITTERS.md file & Update CONTRIBUTING.md Related: APPLINK-20934 --- COMMITTERS.md | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CONTRIBUTING.md | 16 ++++++++-- 2 files changed, 103 insertions(+), 3 deletions(-) create mode 100644 COMMITTERS.md diff --git a/COMMITTERS.md b/COMMITTERS.md new file mode 100644 index 000000000..f4debf609 --- /dev/null +++ b/COMMITTERS.md @@ -0,0 +1,90 @@ +#Committing changes to SDL + +We would like to make it easier for community members to contribute to SDL +using pull requests. This makes the process of contributing a little easier for the contributor since they don't +need to concern themselves with the question, "What branch do I base my changes +on?" This is already called out in the CONTRIBUTING.md. + +##Terminology +Many of these terms have more than one meaning. For the purposes of this +document, the following terms refer to specific things. + +**contributor** - A person who makes a change to SDL and submits a change +set in the form of a pull request. + +**reviewer** - A person responsible for reviewing a pull request. + +**master branch** - [The base branch](https://github.com/smartdevicelink/sdl_core/tree/master). + +**develop branch** - [The branch](https://github.com/LuxoftSDL/sdl_core/tree/develop) where bug fixes against the latest release or release candidate are merged. + +##Pull request checklist +* Add Unit tests. +* All tests pass (see Run all tests section). +* Check component design +* Check amount of required memory, memory leaks. +* Assertion must be used in the right way. +* Are there cyclic dependencies? +* Level of abstraction adequate? +* Are there any platform gotchas? (Does a change make an assumption about + platform specific behavior that is incompatible with other platforms? e.g. + Windows paths vs. POSIX paths). +* Thread safe code. +* No deadlocks. +* Doxygen API documentation available? +* Do you have thread specific comment provided? (if another thread uses added method/classes, + there must be comment which explains: When method will be called by thread? Which thread calls the method? e.g.) +* Do you have specific realization code comments? +* Add log messages. +* There are no Google code style errors. (You can download Google [cppint.py](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py)) +* Check branch naming. +* Check correct commit messages in commits (see Pull request message section). +* Check correct pull request target (`master` or `develop`) +* Check correct pull request message +* Add reviewers + +##Run all tests +* Run in root build directory `make test` + +##Branch naming +Branch name should be: +* `hotfix/` or +* `feature/` or +* `fix/` + +##Pull request message +* Describe the reason why you created pull request and what changes there are. +* Add related Jira ticket as link. + ( EXAMPLE: + `Related: [APPLINK-xxxxx](put direct link here)`) +* If there was an old pull request, add link. ( EXAMPLE: `Old pull request is [here](put direct link here)`) + +##Adding reviewers: +* Add one domain expert +* Add your mentor (for junior developers only) +* Add all junior developers (for junior developers only) + +`Note`: Everyone from SDL team developers can review any pull request (“reviewed” comment is not required) + +##Review process +* Reviewers can leave comments to code only in `commits` tab. +* Contributor must answer each comment (Contributor should specify addressee in comment). +* In case contributor is disagree with reviewer, contributor writes his opinion +* In case contributor is agree with reviewer, contributor leaves link to new commit with changes. +* When reviewer is agree with all changes in pull request, he must leave `Reviewed` comment. + +##Successfully passed review: +* Contributor answered to all comments +* Contributor fixed all mistakes +* All reviewers left `Reviewed` comment + +##Merging +* Successfully passed review. +* Rebase in case of existing conflicts. +* Contributor can squash commits in case of adding same code in different commits. +* Contact @AGaliuzov or @anosach-luxoft to merge pull request. + +##Additional sources +* [Google cppint.py](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py) +* [Git commit best practices](http://chris.beams.io/posts/git-commit/) +* [GitHub Working with formatting](https://help.github.com/articles/working-with-advanced-formatting/) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index db408b7e9..754ea407f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -12,14 +12,24 @@ We use Gitflow ### Pull Requests * Please follow the repository's for all code and documentation. +* All pull requests should be sent to `smartdevicelink/sdl_core/`, in `develop` or `master` branches. * All feature branches should be based on `develop` and have the format `feature/branch_name`. -* Minor bug fixes, that is bug fixes that do not change, add, or remove any public API, should be based on `master` and have the format `hotfix/branch_name`. +* All hotfix branches should be based on `develop` and have the format `fix/branch_name`. +* All new functionality requests should be provided only for `develop` branch. +* In case defect should be fixed in short time (after release), send pull request on `master` and have the format `hotfix/branch_name`. +* In case defect exists in `develop` and `master` branches, send pull request to `develop` only. Do not send the same pull request to the `master` branch. * All pull requests should implement a single feature or fix a single bug. Pull Requests that involve multiple changes (it is our discretion what precisely this means) will be rejected with a reason. -* All commits should separated into logical units, i.e. unrelated changes should be in different commits within a pull request. +* All commits should be separated into logical units, i.e. unrelated changes should be in different commits within a pull request. * Work in progress pull requests should have "[WIP]" in front of the Pull Request title. When you believe the pull request is ready to merge, remove this tag and @mention the appropriate SDL team to schedule a review. * All new code *must* include unit tests. Bug fixes should have a test that fails previously and now passes. All new features should be covered. If your code does not have tests, or regresses old tests, it will be rejected. -* A great example of a pull request can be found here. +* A great example of a [pull request can be found here](https://github.com/smartdevicelink/SmartDeviceLink-iOS/pull/45). ### Contributor's License Agreement (CLA) In order to accept Pull Requests from contributors, you must first sign [the Contributor's License Agreement](https://docs.google.com/forms/d/1VNR8EUd5b46cQ7uNbCq1fJmnu0askNpUp5dudLKRGpU/viewform). If you need to make a change to information that you entered, [please contact us](mailto:justin@livio.io). +## Additional Resources +* [General GitHub documentation](https://help.github.com/) +* [GitHub pull request documentation](https://help.github.com/send-pull-requests/) +* [Contributor's License Agreement](https://docs.google.com/forms/d/1VNR8EUd5b46cQ7uNbCq1fJmnu0askNpUp5dudLKRGpU/viewform) +* [Committers.md](https://github.com/LuxoftSDL/sdl_core/blob/feature/Add_Committers_file/COMMITTERS.md) + -- cgit v1.2.1