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.
The following rules must be followed:
The following rules should be followed:
erlang-mode (emacs) indentation is preferred. This will keep the code base consistent.
vi users are encouraged to give Vim emulation (more info) a try.
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.
Provide a clean branch without merge commits.
As a general rule, any behavioral change to Triq requires a test to go with it. If there's
already a test case, you may have to modify that one.
To run tests, you would do:
$ make test
To give everyone proper credit in addition to the git history, please feel free to append
your name to THANKS in your first contribution.
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
the original commit.
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:
Fix bug 123Add 'foobar' commandChange default timeout to 123