summaryrefslogtreecommitdiff
path: root/doc/workflow.txt
blob: 81bc8667853296c2119fd22b2219416d6c6acd95 (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
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.ilabt.imec.be/git/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.ilabt.imec.be/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.