diff options
-rw-r--r-- | doc/release_policy.rfc.txt | 107 |
1 files changed, 50 insertions, 57 deletions
diff --git a/doc/release_policy.rfc.txt b/doc/release_policy.rfc.txt index b3d72bac4..8fd89f73c 100644 --- a/doc/release_policy.rfc.txt +++ b/doc/release_policy.rfc.txt | |||
@@ -11,66 +11,38 @@ I. Driver | |||
11 | ========= | 11 | ========= |
12 | (What is the problem and what solution did we find?) | 12 | (What is the problem and what solution did we find?) |
13 | 13 | ||
14 | The problem for the GNUnet community stated here is how to evolve the | 14 | In the past it was sometimes unclear when and how the community would reach its |
15 | GNUnet team and code organization, so that developing code gets | 15 | next release. Members were lacking in orientation and felt demotivated. |
16 | attractive again and using GNUnet for testing purposes or even for some | 16 | |
17 | little usecases becomes easier. In the current organizational model | 17 | Another minor concern not yet analysed in depth was the expectation to show the |
18 | bugs tend to accumulate until they are not managable or overwhelming, | 18 | public that the GNUnet project is still active and making progress. With an old |
19 | however, it's clear, that every release candidate should be free from | 19 | release distributed by popular linux distributions it was hard to showcase |
20 | known bugs. There is more. Devs and user need to feel progress to have | 20 | people the GNUnet features and encourage to participate in the project. |
21 | "Erfolgserlebnisse" (roughly: "sense of achievement") and recognition, | 21 | |
22 | like a new release, a "product" they have contributed to, listing new | 22 | To show people how the GNUnet project is releasing its software we hereby |
23 | features with short description of amazing privacy preserving use cases. | 23 | document the current release model: |
24 | 24 | ||
25 | A possible solution to this problem might be a new and lightweighted | 25 | * All main development (e.g. towards 0.12.x) continues on master. |
26 | release model with git. | 26 | * Developers can continue to develop features in their own feature |
27 | 27 | branches, but are encouraged to frequently merge into master (as long as they | |
28 | Release Models with git: | 28 | don't break the build) to avoid divergence and to detect issues from a |
29 | 29 | merge/rebase early. | |
30 | Option 1: | 30 | * 0.11.x releases *must* be protocol-compatible to 0.11.0. So once |
31 | * code organization and branching | 31 | master is NOT protocol-compatible to 0.11.0, development for 0.11.x |
32 | * master branch is release branch, tagged with different version | 32 | must continue in an 0.11-branch where we only cherry-pick those |
33 | numbers development occurs in little side branches | 33 | changes from master that preserve protocol-compatibility. |
34 | * mature code resides in a staging branch for testing and quality | 34 | * better CI may allow us to detect breaking changes before merges in the future |
35 | management | 35 | (but we shall never fault anybody for breaking stuff in master in non-obvious |
36 | * release process | 36 | ways); |
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: (What we really do right now) | ||
60 | * changes that are not expected/known to break anything go into master; | ||
61 | we may be wrong, better CI may allow us to detect breaking changes | ||
62 | before merges in the future (but we shall never fault anybody for | ||
63 | breaking stuff in master in non-obvious ways); | ||
64 | * experimental development happens in branches, created by individuals | ||
65 | or groups as they see fit. They are encouraged to merge often (if that | ||
66 | would not break anything) to avoid divergence and to detect issues from | ||
67 | a merge/rebase early. | ||
68 | * actual _release policy_: | 37 | * actual _release policy_: |
69 | - tests must pass | 38 | - tests must pass |
70 | - no compiler warnings for -Wall | 39 | - no compiler warnings for -Wall |
71 | - acceptance tests (manual feature test) must succeed | 40 | - acceptance tests (manual feature test) must succeed |
72 | - no known "release critical" bugs (where RC has no formal definition, | 41 | - no known "release critical" bugs (where RC has no formal definition, |
73 | mostly we rather explicitly declare certain bugs as "not critical") | 42 | mostly we rather explicitly declare certain bugs as "not critical") |
43 | - Whenever API changes happen the person making that changes should update | ||
44 | dependencies or at least work with people who hack on the dependencies to | ||
45 | cooridnate the adjustments | ||
74 | o buildbots are happy (if running) | 46 | o buildbots are happy (if running) |
75 | o static analysis is happy (if available, false-positives => ignore) | 47 | o static analysis is happy (if available, false-positives => ignore) |
76 | o documentation is reasonably up-to-date | 48 | o documentation is reasonably up-to-date |
@@ -80,10 +52,8 @@ Option 3: (What we really do right now) | |||
80 | almost ready to be merged? | 52 | almost ready to be merged? |
81 | Legend: -: absolutely mandatory; o: important; +: nice to have | 53 | Legend: -: absolutely mandatory; o: important; +: nice to have |
82 | 54 | ||
83 | ... | ||
84 | 55 | ||
85 | Option 1 and 2 are two flavours describe in | 56 | For further information see: https://trunkbaseddevelopment.com/ |
86 | https://trunkbaseddevelopment.com/ | ||
87 | 57 | ||
88 | II. Evaluation Criteria | 58 | II. Evaluation Criteria |
89 | ======================= | 59 | ======================= |
@@ -103,6 +73,12 @@ is what you are motivated to do, you will not get stable, well-tested | |||
103 | code. I don't have a magic bullet to motivate you to write more tests, | 73 | code. I don't have a magic bullet to motivate you to write more tests, |
104 | or to improve existing tests. -CG | 74 | or to improve existing tests. -CG |
105 | 75 | ||
76 | Your argument is good. Two or three of us thought that the problem is about | ||
77 | missing releases which we feld demotivating. We thought, we were stucked | ||
78 | somewhere. But as you state, it is us not doing the necessary work. What I | ||
79 | still find useful is to document the release process. In consequence I | ||
80 | changed the problem statement. -xrs | ||
81 | |||
106 | I also disagree that releases have to be 'known bug free'. That bar is | 82 | I also disagree that releases have to be 'known bug free'. That bar is |
107 | way too high. However, there are obviously 'critical' bugs, but what | 83 | way too high. However, there are obviously 'critical' bugs, but what |
108 | they are is another debate. But not all bugs are critical. Also, | 84 | they are is another debate. But not all bugs are critical. Also, |
@@ -110,6 +86,8 @@ I would distinguish between 'standard' and 'experimental' subsystems. | |||
110 | Experimental subsystems should build. They don't have to run, or do | 86 | Experimental subsystems should build. They don't have to run, or do |
111 | anything useful. Not even tests have to pass for a release IMO. -CG | 87 | anything useful. Not even tests have to pass for a release IMO. -CG |
112 | 88 | ||
89 | Thank you, I agree and changed it. -xrs | ||
90 | |||
113 | Git is also not a "release model". Git is a software development | 91 | Git is also not a "release model". Git is a software development |
114 | tool. But introducing branches in Git won't fix bugs. It also won't | 92 | tool. But introducing branches in Git won't fix bugs. It also won't |
115 | improve test coverage. It won't test the code on a broad range of | 93 | improve test coverage. It won't test the code on a broad range of |
@@ -125,6 +103,16 @@ as Option 1 is already largely done, except that certain CI tasks | |||
125 | simply cannot be productively done pre-merge right now (and I'm all | 103 | simply cannot be productively done pre-merge right now (and I'm all |
126 | for improving that situation). -CG | 104 | for improving that situation). -CG |
127 | 105 | ||
106 | With resprect to changes kept in branches the reason why I personally keep | ||
107 | changes back is because it takes very long for me to get something really | ||
108 | working in C. Before that I either not worth it or I don't want to blame | ||
109 | other before not being sure it's not my fault. | ||
110 | |||
111 | Can we track branches? Can we write a little cronjob that checks for branches | ||
112 | that are to long undercover with the aim to recommend the responsible person | ||
113 | to merge soon? | ||
114 | - xrs | ||
115 | |||
128 | Finally, there is one last elephant with respect to branches and | 116 | Finally, there is one last elephant with respect to branches and |
129 | merging that I would like you to consider. Given that GNUnet is highly | 117 | merging that I would like you to consider. Given that GNUnet is highly |
130 | modular, you have largely benefited from the modular architecture and | 118 | modular, you have largely benefited from the modular architecture and |
@@ -148,6 +136,8 @@ somewhere is impractical. So at least at times where "major" API | |||
148 | rewrites are happening, it is important to minimize the number of | 136 | rewrites are happening, it is important to minimize the number of |
149 | branches. -CG | 137 | branches. -CG |
150 | 138 | ||
139 | Thank you for clarifying. I added the API aspect above. -xrs | ||
140 | |||
151 | 141 | ||
152 | IV. Doing | 142 | IV. Doing |
153 | ========= | 143 | ========= |
@@ -178,6 +168,9 @@ Let me list what I think needs doing: | |||
178 | 168 | ||
179 | Note that none of this really adds up to a "release policy". | 169 | Note that none of this really adds up to a "release policy". |
180 | 170 | ||
171 | We should thing and talk about point 2 and 3 more in depth with the question | ||
172 | in mind, how to make this task more attractive for the community :-) | ||
173 | |||
181 | 174 | ||
182 | V. Previous Versions | 175 | V. Previous Versions |
183 | ==================== | 176 | ==================== |