blob: a829192bbe658288b17e4253f0d66b72a8a15c1c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
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-rina
on Freenode (IRC chat). Use whatever name you desire.
2. Coding guidelines
The Ouroboros stack is written in C and has the GPL license. It uses
autotools as the build system. 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. Example:
int * a;
instead of
int *a;
- Don't explicitly cast malloc, but do
ptr = malloc (sizeof(*ptr) * len);
or
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. Incrementing MAJOR is used
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.
3.1. Repository structure
The main git repository can be found at:
https://bitbucket.org/ouroboros-rina/stack
It contains the following branches:
- master: Contains the most stable versions of the stack.
- testing: Contains tested version but may still contain bugs.
- be: Contains untested but compiling code.
All new contributions are integrated into ‘be’ from forks of the main
git repository. 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.
3.2. Contributions
There are 3 ways to provide contributions:
- bitbucket pull-requests: via bitbucket UI
- git email pull-requests: via mailing list (ouroboros@freelists.org)
- 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
3.4 Bugs
Bugs are reported through the bitbucket issue tracker
(https://bitbucket.org/ouroboros-rina/stack/issues?status=new&status=open). The
process of reporting a bug is the following:
a. Report the bug on the issue tracker
b. Sync with the HEAD of the most stable branch where the bug is
present
c. Provide a bug fix
d. Request a pull request to that branch
e. The bugfix will be merged upwards into the less stable branches
Note that step a is always required. Steps b-e 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. A next version is discussed through a conference call,
after which the agreed upon features are added to the issue
tracker. Version 1.0 of Ouroboros will contain minimal functionality
to have a RINA implementation. Pull requests containing non discussed
features will be automatically rejected and will revoke you the rights
to perform new pull requests.
|
