Ouroboros Contributions

 This page is under construction  

How to contribute to Ouroboros.

Ongoing work

Ouroboros is far from complete. Plenty of things need to be researched and implemented. We don’t really keep a list, but this epic board can give you some ideas of what is still on our mind and where you may be able to contribute.

Communication

There are 2 ways that are used to communicate: The | mailing list (ouroboros@freelists.org) will be used for almost everything except for day-to-day chat. For that we use a public slack channel slack (| invite link) bridged to a matrix space | invite link. Use the tool you prefer and whatever login name you desire.

Introduce yourself, use common sense and be polite!

Code contributions

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. 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’. Most users should probably use master.

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.

Contributions

Providing contributions can be done by sending git patches to the mailing list (ouroboros@freelists.org).

To set this up, add the following to your git config

Commit messages

A commit message should follow these 10 simple rules, based on (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

Bugs

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

   Provide a description of the bug
   Provide system logs
   Provide a minimal code example to reproduce the bug if possible
   Check if the bug is still present in the be branch
   Sync with the HEAD of the most stable branch where the bug is present
   Provide a bug fix if you can, send a patch to the mailing list

Note that the first 2 steps are always required by the bug reporter. 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.

We’re a small community. Rome wasn’t built in a day.