Note: this Wiki has been deprecated. Newer versions of this page are now at Contributing to Suricata.

Contributing¶

This guide describes what steps to take if you want to contribute a patch or patchset to Suricata.
Before you start, please review and sign our Contribution Agreement

Open (or claim) a ticket¶

For features and bugs we need tickets. For really trivial fixes or cleanups we won't need it.

Assign the ticket to yourself. For this you will need to have the "developer" role. Please get in touch with us to request this role.

If a ticket is already assigned to someone, please contact us or that person first.

What branch to work on¶

There are 2 active branches:
master-x.x.x (e.g. master-4.x.y)
master

The former is the stable branch. The latter the development branch. The stable branch should only be worked on for important bug fixes.

Development of new features or large scale redesign is done in the development branch.

If in doubt, please check with us first.

Create your own branch¶

It's useful to create descriptive branch names. If you're working on ticket 123 to improve GeoIP? Name your branch "geoip-feature-123-v1". The "-v1" addition for feedback. When incorporating feedback you will have to create a new branch for each pull request. So when you address the first feedback, you will work in "geoip-feature-123-v2" and so on.

Github: Creating a branch with Github
Git: Creating a branch with Git

Coding Style¶

We have a Coding Style that needs to be followed.

Commit locally¶

Please consider the Commit Criteria.

Send a pull request¶

The pull request is used to request inclusion of your patches into the main repository. Before it is merged, it will be reviewed and pushed through a QA process.

Please consider our Pull Request Criteria when submitting.

Github: Pull Request Using Github
Git: Sending your work by email

On github we have continuous integration enabled. This means some automated build and unittests are performed on the pull request. Generally this is ready after a few minutes. If the test fails, the pull request won't be considered.

Feedback¶

You'll likely get some feedback. Even our most experienced devs do, so don't feel bad about it.

After discussing the feedback on github or by email, it's time to go back to (create your own branch) and do it all again. This process can iterate quite a few times.

Merged! Cleanup¶

Congrats! Your change has been merged into the main repository. Lets clean up.

You can now delete your branches, both locally and at github.

Update ticket¶

You can now put the url of the merged pull request in the redmine ticket.
Next, mark the ticket as "Closed" or "Resolved"