diff options
Diffstat (limited to 'release_policy.rfc')
-rw-r--r-- | release_policy.rfc | 87 |
1 files changed, 87 insertions, 0 deletions
diff --git a/release_policy.rfc b/release_policy.rfc new file mode 100644 index 000000000..987acf29c --- /dev/null +++ b/release_policy.rfc | |||
@@ -0,0 +1,87 @@ | |||
1 | *********************************************************************** | ||
2 | ********************* Release Policy (RFC) **************************** | ||
3 | *********************************************************************** | ||
4 | |||
5 | We suggest this structure of the proposal document as part of a tiny | ||
6 | social process in order to find a decision in a cooperativ and common | ||
7 | way. | ||
8 | |||
9 | |||
10 | I. Driver | ||
11 | ========= | ||
12 | (What is the problem and what solution did we find?) | ||
13 | |||
14 | The problem for the GNUnet community stated here is how to evolve the | ||
15 | GNUnet team and code organization, so that developing code gets | ||
16 | attractive again and using GNUnet for testing purposes or even for some | ||
17 | little usecases becomes easier. In the current organizational model | ||
18 | bugs tend to accumulate until they are not managable or overwhelming, | ||
19 | however, it's clear, that every release candidate should be free from | ||
20 | known bugs. There is more. Devs and user need to feel progress to have | ||
21 | "Erfolgserlebnisse" (roughly: "sense of achievement") and recognition, | ||
22 | like a new release, a "product" they have contributed to, listing new | ||
23 | features with short description of amazing privacy preserving use cases. | ||
24 | |||
25 | A possible solution to this problem might be a new and lightweighted | ||
26 | release model with git. | ||
27 | |||
28 | Release Models with git: | ||
29 | |||
30 | Option 1: | ||
31 | * code organization and branching | ||
32 | * master branch is release branch, tagged with different version | ||
33 | numbers development occurs in little side branches | ||
34 | * mature code resides in a staging branch for testing and quality | ||
35 | management | ||
36 | * release process | ||
37 | * development in little side branches | ||
38 | * if code is mature, merge with staging branch and do testing, | ||
39 | * static/dynamic analysis and code audits if checks are okay, merge | ||
40 | with release branch and tag with new version number | ||
41 | |||
42 | Option 2: | ||
43 | * code organization and branching | ||
44 | * master branch is development branch | ||
45 | * further development task can be done in other side branches | ||
46 | for every release candidate exists a new branch called after the | ||
47 | version number | ||
48 | * release process | ||
49 | * development in master and side branches | ||
50 | * if code of side branches is mature merge with master branch | ||
51 | * if code in master branch is mature, create if not existant a new | ||
52 | * release branch called after the new version number and merge with | ||
53 | master | ||
54 | * in the release branch do testing, static/dynamic analysis | ||
55 | and code audits | ||
56 | * if checks are okay, tag as release candidate | ||
57 | |||
58 | |||
59 | Option 3: | ||
60 | ... | ||
61 | |||
62 | Option 1 and 2 are two flavours describe in | ||
63 | https://trunkbaseddevelopment.com/ | ||
64 | |||
65 | II. Evaluation Criteria | ||
66 | ======================= | ||
67 | (what are criterias to interprete the results as success if we review | ||
68 | the problem and solution after a year or so) | ||
69 | |||
70 | III. Concerns (of team members) | ||
71 | =============================== | ||
72 | (if there are concerns of team members, write them down here to later | ||
73 | review) | ||
74 | |||
75 | IV. Doing | ||
76 | ========= | ||
77 | (who does what within which time frame?) | ||
78 | |||
79 | V. Previous Versions | ||
80 | ==================== | ||
81 | (if we found some flaws in the solution, and we want to change the | ||
82 | release policy, we document the old ones here als previous versions. | ||
83 | the goal is establish a learn process.) | ||
84 | |||
85 | IV. References | ||
86 | ============== | ||
87 | (if there are references to paper, web pages and other sources.) | ||