diff options
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 67 |
1 files changed, 23 insertions, 44 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e0de0eb..4643725 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,7 +1,7 @@ Contributing to rebar --------------------- -Before implementing a new feature, please submit a ticket to discuss your plans. +Before implementing a new feature, please submit a ticket to discuss your plans. The feature might have been rejected already, or the implementation might already be decided. See [Community and Resources](README.md#community-and-resources). @@ -16,20 +16,20 @@ The following rules must be followed: The following rules should be followed: * Write small functions whenever possible - * Avoid having too many clauses containing clauses containing clauses. + * Avoid having too many clauses containing clauses containing clauses. Basically, avoid deeply nested functions. [erlang-mode (emacs)](http://www.erlang.org/doc/man/erlang.el.html) -indentation is preferred. This will keep the code base consistent. +indentation is preferred. This will keep the code base consistent. vi users are encouraged to give [Vim emulation](http://emacswiki.org/emacs/Evil) ([more info](https://gitorious.org/evil/pages/Home)) a try. Pull requests and branching --------------------------- -Use one topic branch per pull request. If you do that, you can add extra commits or fix up -buggy commits via `git rebase -i`, and update the branch. The updated branch will be -visible in the same pull request. Therefore, you should not open a new pull request when +Use one topic branch per pull request. If you do that, you can add extra commits or fix up +buggy commits via `git rebase -i`, and update the branch. The updated branch will be +visible in the same pull request. Therefore, you should not open a new pull request when you have to fix your changes. Do not commit to master in your fork. @@ -39,65 +39,44 @@ Provide a clean branch without merge commits. Tests ----- -As a general rule, any behavioral change to rebar requires a test to go with it. If there's -already a test case, you may have to modify that one. If there isn't a test case or a test -suite, add a new test case or suite in `inttest/`. [retest](https://github.com/dizzyd/retest) based tests are preferred, but -we also have EUnit tests in `test/`. +As a general rule, any behavioral change to rebar requires a test to go with it. If there's +already a test case, you may have to modify that one. If there isn't a test case or a test +suite, add a new test case or suite in `test/`. -Say you've added a new test case in `inttest/erlc`. To only execute the modified suite, -you would do the following: ```sh -# First we build rebar and its deps to also get `deps/retest/retest` -$ make debug deps -# Now we can test the modified erlc suite -$ deps/retest/retest -v inttest/erlc +$ ./bootstrap +$ ./rebar3 ct ``` -To test EUnit tests, you would do: -```sh -$ make debug -$ ./rebar -v eunit -``` - -You can also run `make test` to execute both EUnit and [retest](https://github.com/dizzyd/retest) tests as `make check` does. - Credit ------ -To give everyone proper credit in addition to the git history, please feel free to append +To give everyone proper credit in addition to the git history, please feel free to append your name to `THANKS` in your first contribution. Committing your changes ----------------------- -Please ensure that all commits pass all tests, and do not have extra Dialyzer warnings. -To do that run `make check`. If you didn't build via `make debug` at first, the beam files in -`ebin/` might be missing debug_info required for [xref](http://www.erlang.org/doc/man/xref.html) -and [Dialyzer](http://www.erlang.org/doc/man/dialyzer.html), causing a test -failure. -If that happens, running `make clean` before running `make check` could solve the problem. -If you change any of the files with known but safe to ignore Dialyzer warnings, you may -have to adapt the line number(s) in [dialyzer_reference](dialyzer_reference). If you do that, -do not remove the -leading blank line. +Please ensure that all commits pass all tests, and do not have extra Dialyzer warnings. +To do that run `./rebar3 ct` and `./rebar3 as dialyze dialyzer`. #### Structuring your commits -Fixing a bug is one commit. -Adding a feature is one commit. -Adding two features is two commits. +Fixing a bug is one commit. +Adding a feature is one commit. +Adding two features is two commits. Two unrelated changes is two commits. -If you fix a (buggy) commit, squash (`git rebase -i`) the changes as a fixup commit into +If you fix a (buggy) commit, squash (`git rebase -i`) the changes as a fixup commit into the original commit. #### Writing Commit Messages -It's important to write a proper commit title and description. The commit title must be -at most 50 characters; it is the first line of the commit text. The second line of the -commit text must be left blank. The third line and beyond is the commit message. You -should write a commit message. If you do, wrap all lines at 72 characters. You should -explain what the commit does, what references you used, and any other information +It's important to write a proper commit title and description. The commit title must be +at most 50 characters; it is the first line of the commit text. The second line of the +commit text must be left blank. The third line and beyond is the commit message. You +should write a commit message. If you do, wrap all lines at 72 characters. You should +explain what the commit does, what references you used, and any other information that helps understanding your changes. Basically, structure your commit message like this: |