summaryrefslogtreecommitdiff
path: root/doc/workflow.txt
blob: 0f59b4bf7d41d4545f3b513df9b615288a84d4bd (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

your * = malloc (sizeof (*your) * len);
or
your * = malloc (sizeof *your * 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.