diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/en/docs/Contributions/_index.md | 112 |
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. |