and commit history, there are several *rules* required for each contribution.
## Contributing Code Or Content ##
+
### Basic Rules ###
* github pull requests are the favourited mechanism to submit contributions
* a module (code inside subfolder modules/)
* a tool (code inside subfolder utils/)
* an example or main configs (files inside subfolders etc/ or examples/)
- * commit messages **should** be formatted as specified in the next section
+ * commit messages **has to be formatted** as specified in the next section
* commit message must describe the changes done by the patch
* other details (e.g., how to reproduce, backtrace, sip packets, ...) belong
to content (comments) of the pull request
likely to rise merge conflicts. With separate commit, that won't be
backported, only the commit to xml doc file, then README will be manually
regenerated in the corresponding branch.
+ * code **should** be formatted with **clang-format** or to match the style of
+ the component that the commit applies to. The `.clang-format` file is part of
+ Kamailio source code tree, in the root folder.
### Commit Message Format ###
generating the Changelog (e.g. git log --pretty=oneline).
Please start always with the prefix of the component (subsystem) that is modified by the commit, for example:
- * core: typo fixes to log messages
- * tcp: stun fixes
- * mem: added faster malloc
- * module_name: support for foo rfc extension
- * lib_name: critical bug fix for abc case
- * kamctl: added support for management of module xyz
+ * `core`: typo fixes to log messages
+ * `tcp`: stun fixes
+ * `mem`: added faster malloc
+ * `module_name`: support for foo rfc extension
+ * `lib_name`: critical bug fix for abc case
+ * `kamctl`: added support for management of module xyz
#### Examples Of Commit Messages ####