Project

General

Profile

Code Submission Quality Criteria

Coding Style

Coding style still needs more documentation. Working on that here: Coding Style

Also, check the existing code. If yours is wildly different, it's wrong.
Example: https://github.com/inliniac/suricata/blob/master/src/decode-ethernet.c

Commits

  1. commits need to be logically separated. Don't fix unrelated things in one commit.
  2. don't add unnecessary commits, if commit 2 fixes commit 1 merge them together (squash)
  3. commits need to have proper messages, explaining anything that is non-trivial
  4. commits should not at the same time change, rename and/or move code
  5. documentation updates should be in their own commit (not mixed with code commits)
  6. commit messages need to be properly formatted:
    • meaningful and short (50 chars max) subject line followed by an empty line
    • description, wrapped at ~72 characters
Information that needs to be part of a commit (if applicable):
  1. ticket it fixes. E.g. "Fixes Bug #123."
  2. compiler warning it addresses
  3. Coverity Scan issue it addresses
  4. static analyzer error it fixes (cppcheck/scan-build/etc)
  5. Naming convention: prefix message with sub-system ("rule parsing: fixing foobar").

Pull Requests

A github pull request is actually just a pointer to a branch in your tree. Github provides a review interface that we use.

  1. a branch can only be used in one single PR
  2. a branch should not be updated after the pull request
  3. a pull request always needs a good description (link to issue tracker if related to a ticket).
  4. incremental pull requests need to link to the prior iteration
  5. incremental pull requests need to describe changes since the last PR
  6. link to the ticket(s) that are addressed to it
  7. links to the prscript builds*
  8. pull requests are automatically tested using travis-ci (https://travis-ci.org/inliniac/suricata/pull_requests). Failing builds won't be consider and should be closed immediately.
  9. pull requests that change, or add a feature should include a documentation update commit

(*) access to prscript is limited to trusted devs. For the rest of you, ask Victor, Eric, Andreas or Jason to run it for you.

Tests and QA

As much as possible, new functionality should be easy to QA.

  1. add unittests where possible
  2. provide pcaps
  3. provide example rules if the code added new keywords or new options to existing keywords