aboutsummaryrefslogtreecommitdiff
path: root/content/en
diff options
context:
space:
mode:
Diffstat (limited to 'content/en')
-rw-r--r--content/en/docs/Contributions/_index.md112
1 files changed, 43 insertions, 69 deletions
diff --git a/content/en/docs/Contributions/_index.md b/content/en/docs/Contributions/_index.md
index b9ae950..08fdb32 100644
--- a/content/en/docs/Contributions/_index.md
+++ b/content/en/docs/Contributions/_index.md
@@ -7,7 +7,7 @@ description: >
How to contribute to Ouroboros.
---
-1. Communication
+### Communication
There are 2 ways that will be used to communicate: The mailing list
(ouroboros@freelists.org) will be used for almost everything except
@@ -18,7 +18,7 @@ bit more active, and preferred. Use whatever login name you desire.
Introduce yourself, use common sense and be polite!
-2. Coding guidelines
+### Coding guidelines
The coding guidelines of the main Ouroboros stack are similar as those
of the Linux kernel
@@ -26,38 +26,31 @@ of the Linux kernel
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:
-
-```C
-int * a;
-```
+ ```C
+ int * a;
+ ```
instead of
-
-```C
-int *a;
-```
-
+ ```C
+ int *a;
+ ```
- Don't explicitly cast malloc, but do
-
-```C
-ptr = malloc(sizeof(*ptr) * len);
-```
-
+ ```C
+ ptr = malloc(sizeof(*ptr) * len);
+ ```
- When checking for invalid pointers use
-
-```C
-if (ptr == NULL)
-```
+ ```C
+ if (ptr == NULL)
+ ```
instead of
-```C
-if (!ptr)
-```
+ ```C
+ if (!ptr)
+ ```
When in doubt, just browse the code a bit. It's not rocket science.
-3. Development workflow
+### 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
@@ -66,7 +59,7 @@ 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
+#### Repository structure
The main git repository can be found at:
https://ouroboros.rocks/cgit/ouroboros
@@ -74,9 +67,7 @@ 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
@@ -85,68 +76,51 @@ 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
+#### Contributions
-There is 1 way to provide contributions:
-
-- git email patch: via mailing list (ouroboros@freelists.org)
+Providing contributions can be done by sending git patches to the
+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
+#### Commit messages
-A commit message should follow these 9 simple rules (adjusted from
+A commit message should follow these 10 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
+1. Separate subject from body with a blank line
+2. Limit the subject line to 50 characters
+3. Capitalize the subject line
+4. Do not end the subject line with a period
+5. Use the imperative mood in the subject line
+6. Precede the subject line by indicating the component where changes were made
+7. Wrap the body at 72 characters
+8. Use the body to explain what and why vs. how
+9. If the commit addresses a bug, reference it in the body
+10. Sign off your commits using the signoff feature in git
-- 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
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
+1. Provide a description of the bug
+2. Provide system logs
+3. Provide a minimal code example to reproduce the bug if possible
+4. Check if the bug is still present in the be branch
+5. Sync with the HEAD of the most stable branch where the bug is present
+6. 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.
-4. New features
+### 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 are likely to be
-rejected.
+discussed.
We're a small community. Rome wasn't built in a day.