Development guide

Coding style

Please try to keep current coding style, so we don't end up with mess.

Patches

Patches should be attached to (new) tickets in our ticket system. When starting to work on something, please do assign yourself to a particular ticket/task (or create a new one if not present) to avoid duplicate work. We don't use Changelog files - we aggegate the tickets on a per-version basis to get a quick overview of what changed. By contributing code, you accept that your code goes under copyright of respective module copyright owner/s.

Note: this is only for contributors, developers can commit to repository if they are sure everything works.

Tickets

When opening tickets please fill them properly (email, description, type, priority, milestone, version, keywords, and component).

Commit policy

We're not using Changelog files so please be descriptive in your commit messages. A general rule of a thumb is to make more small commits instead of one huge commit. Please think about that while coding. Obviously, make sure you've read the coding style guidelines.

Features freeze

In general, two weeks before the release is about to happen we will stop implementing new features, and start extensive bug hunting and regression tests. We will create milestone branch out of trunk, and start stabilization period. This period will be used to focus on fixing any remaining bugs for the release.