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
|
***********************************************************************
********************* Release Policy (RFC) ****************************
***********************************************************************
We suggest this structure of the proposal document as part of a tiny
social process in order to find a decision in a cooperativ and common
way.
I. Driver
=========
(What is the problem and what solution did we find?)
The problem for the GNUnet community stated here is how to evolve the
GNUnet team and code organization, so that developing code gets
attractive again and using GNUnet for testing purposes or even for some
little usecases becomes easier. In the current organizational model
bugs tend to accumulate until they are not managable or overwhelming,
however, it's clear, that every release candidate should be free from
known bugs. There is more. Devs and user need to feel progress to have
"Erfolgserlebnisse" (roughly: "sense of achievement") and recognition,
like a new release, a "product" they have contributed to, listing new
features with short description of amazing privacy preserving use cases.
A possible solution to this problem might be a new and lightweighted
release model with git.
Release Models with git:
Option 1:
* code organization and branching
* master branch is release branch, tagged with different version
numbers development occurs in little side branches
* mature code resides in a staging branch for testing and quality
management
* release process
* development in little side branches
* if code is mature, merge with staging branch and do testing,
* static/dynamic analysis and code audits if checks are okay, merge
with release branch and tag with new version number
Option 2:
* code organization and branching
* master branch is development branch
* further development task can be done in other side branches
for every release candidate exists a new branch called after the
version number
* release process
* development in master and side branches
* if code of side branches is mature merge with master branch
* if code in master branch is mature, create if not existant a new
* release branch called after the new version number and merge with
master
* in the release branch do testing, static/dynamic analysis
and code audits
* if checks are okay, tag as release candidate
Option 3:
...
Option 1 and 2 are two flavours describe in
https://trunkbaseddevelopment.com/
II. Evaluation Criteria
=======================
(what are criterias to interprete the results as success if we review
the problem and solution after a year or so)
III. Concerns (of team members)
===============================
(if there are concerns of team members, write them down here to later
review)
IV. Doing
=========
(who does what within which time frame?)
V. Previous Versions
====================
(if we found some flaws in the solution, and we want to change the
release policy, we document the old ones here als previous versions.
the goal is establish a learn process.)
IV. References
==============
(if there are references to paper, web pages and other sources.)
|
