1. Communication

There are 2 ways that will be used to communicate: The mailing list
(ouroboros@freelists.org) will be used for almost everything except
for day-to-day chat. For that we will use the channel #ouroboros on
Freenode (IRC chat). Use whatever name you desire.

2. Coding guidelines

The coding guidelines of the Ouroboros stack are the same as those of
the Linux kernel
(https://www.kernel.org/doc/Documentation/CodingStyle) with the
following exceptions:

- Soft tabs are to be used instead of hard tabs

- A space is to be inserted between a pointer and its object name upon
  declaration or in function signatures. Example:

int * a;
instead of
int *a;

- Don't explicitly cast malloc, but do

ptr = malloc(sizeof(*ptr) * len);

- When checking for invalid pointers use

if (ptr == NULL)
instead of
if (!ptr)

3. Development workflow

Git is used as a version tooling for the code. Releases are identified
through a git tag by a number MAJOR.MICRO.PATCHLEVEL. Incrementing
MAJOR is done to indicate a big step ahead in terms of features; it is
discussed when new features are planned. Incrementing MICRO is done
when APIs/ABIs are not necessarily compatible. The PATCHLEVEL is
incremented when an urgent bugfix is incorporated.

3.1. Repository structure

The main git repository can be found at:
https://ouroboros.rocks/cgit/ouroboros

It contains the following branches:

- master: Contains the most stable versions of Ouroboros.

- testing: Contains tested code but may still contain bugs.

- be: Contains untested but compiling code.

All new contributions are integrated into 'be' through patches sent to
the mailing list. Once a version of 'be' is tested enough, it is
merged into 'testing'. When a 'testing' version is considered stable
enough, it is merged into 'master'. Users should ALWAYS use master
unless told otherwise.

3.2. Contributions

There is 1 ways to provide contributions:

- git email patch: via mailing list (ouroboros@freelists.org)

New development is ALWAYS done against the 'be' branch of the main git
repository. Contributions are always made using your real name and
real e-mail address.

3.3 Commit messages

A commit message should follow these 9 simple rules (adjusted from
http://chris.beams.io/posts/git-commit/):

- Separate subject from body with a blank line

- Limit the subject line to 50 characters

- Capitalize the subject line

- Do not end the subject line with a period

- Use the imperative mood in the subject line

- Precede the subject line by indicating the component where changes
were made

- Wrap the body at 72 characters

- Use the body to explain what and why vs. how

- If the commit addresses a bug, reference it in the body

- Sign off your commits using the signoff feature in git

3.4 Bugs

Bugs are reported through the Bugzilla issue tracker
(https://ouroboros.rocks/bugzilla/). The process of reporting
a bug is the following:

a. Provide a description of the bug

b. Provide system logs

c. Provide a minimal code example to reproduce the bug

d. Sync with the HEAD of the most stable branch where the bug is
present

e. Provide a bug fix if you can

f. Send a patch to the mailing list

g. The bugfix will be merged upwards into the less stable branches

Note that step a and b are always required. Steps c-g may be performed
by someone else.

4. New features

New features can be always be requested through the mailing list. They
will be taken into account when a next version of the prototype is
discussed. Patches containing non discussed features will be
automatically rejected.