diff options
author | Christian Grothoff <christian@grothoff.org> | 2018-03-30 18:32:37 +0200 |
---|---|---|
committer | Christian Grothoff <christian@grothoff.org> | 2018-03-30 18:32:37 +0200 |
commit | d9c9f4dd2f61620d1848c8c32a36341ec1f1e41e (patch) | |
tree | ba2efc3b3399f6e88f4934cf960d42925991b244 /release_policy.rfc | |
parent | e7676dee608ad5140513c05911645a0d6abf9b16 (diff) | |
download | gnunet-d9c9f4dd2f61620d1848c8c32a36341ec1f1e41e.tar.gz gnunet-d9c9f4dd2f61620d1848c8c32a36341ec1f1e41e.zip |
comments on rP
Diffstat (limited to 'release_policy.rfc')
-rw-r--r-- | release_policy.rfc | 105 |
1 files changed, 104 insertions, 1 deletions
diff --git a/release_policy.rfc b/release_policy.rfc index 987acf29c..fd4118742 100644 --- a/release_policy.rfc +++ b/release_policy.rfc | |||
@@ -56,7 +56,30 @@ Option 2: | |||
56 | * if checks are okay, tag as release candidate | 56 | * if checks are okay, tag as release candidate |
57 | 57 | ||
58 | 58 | ||
59 | Option 3: | 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_: | ||
69 | - tests must pass | ||
70 | - no compiler warnings for -Wall | ||
71 | - acceptance tests (manual feature test) must succeed | ||
72 | - no known "release critical" bugs (where RC has no formal definition, | ||
73 | mostly we rather explicitly declare certain bugs as "not critical") | ||
74 | o buildbots are happy (if running) | ||
75 | o static analysis is happy (if available, false-positives => ignore) | ||
76 | o documentation is reasonably up-to-date | ||
77 | + reasonable test coverage (if too terrible => move subsystem to experimental?) | ||
78 | + texinfo (HTML+PDF) and doxygen happy? Ideally without warnings! | ||
79 | + nobody screaming bloody murder because of almost-completed features/bugfixes | ||
80 | almost ready to be merged? | ||
81 | Legend: -: absolutely mandatory; o: important; +: nice to have | ||
82 | |||
60 | ... | 83 | ... |
61 | 84 | ||
62 | Option 1 and 2 are two flavours describe in | 85 | Option 1 and 2 are two flavours describe in |
@@ -72,10 +95,90 @@ III. Concerns (of team members) | |||
72 | (if there are concerns of team members, write them down here to later | 95 | (if there are concerns of team members, write them down here to later |
73 | review) | 96 | review) |
74 | 97 | ||
98 | I disagree that "bugs tend to accumulate until they are not managable". | ||
99 | The real issue is that neither writing testcases nor fixing bugs are | ||
100 | fun tasks volunteers like to do. As you write yourself: you want a | ||
101 | sense of achievement, recognition, "new features". So as long as that | ||
102 | 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, | ||
104 | or to improve existing tests. -CG | ||
105 | |||
106 | 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 | ||
108 | they are is another debate. But not all bugs are critical. Also, | ||
109 | I would distinguish between 'standard' and 'experimental' subsystems. | ||
110 | 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 | ||
112 | |||
113 | 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 | ||
115 | improve test coverage. It won't test the code on a broad range of | ||
116 | platforms. It also doubt it will give you the recognition you crave. | ||
117 | More importantly, what you describe is already happening, and | ||
118 | partially has contributed to the problems. Bart kept his own CADET | ||
119 | hacks in his personal branch for years, hence without much feedback or | ||
120 | review. The SecuShare team kept their patches in their own branch, | ||
121 | hence revealing interesting failure modes when it was finally merged. | ||
122 | Martin kept some of his ABE-logic in his own branch (that one was | ||
123 | merged without me noticing major problems). Anyway, what you propose | ||
124 | 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 | ||
126 | for improving that situation). -CG | ||
127 | |||
128 | 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 | ||
130 | modular, you have largely benefited from the modular architecture and | ||
131 | been able to hack in your respective corners, unaffected by other | ||
132 | modules (modulo bugs in dependencies). That is great, and the desired | ||
133 | development mode. It has the critical advantage that bugs in modules | ||
134 | that nobody depends upon (auction, rps, social) can be in 'master' and | ||
135 | won't disturb anything. As most new development usually happens on the | ||
136 | leaves of the dependency graph, that is great. However, occasionally | ||
137 | there are architectural changes. Not of the type where the graph | ||
138 | changes, but where key API assumptions change. We recently had one for | ||
139 | the GNU Name System with the dropping of ".gnu". Before, CADET | ||
140 | changed the semantics and paramter for 'port'. In the future, CORE | ||
141 | will introduce protocol versioning. Whenever such a change happens, | ||
142 | it usually falls upon the person making that change to update | ||
143 | dependencies as well (or at least to work with people who hack on the | ||
144 | dependencies to coordinate the adjustments). That way, changing an | ||
145 | API for in-tree dependencies is a minor nuisance. However, if | ||
146 | branches exist, making sure that API changes do not break _any_ branch | ||
147 | somewhere is impractical. So at least at times where "major" API | ||
148 | rewrites are happening, it is important to minimize the number of | ||
149 | branches. -CG | ||
150 | |||
151 | |||
75 | IV. Doing | 152 | IV. Doing |
76 | ========= | 153 | ========= |
77 | (who does what within which time frame?) | 154 | (who does what within which time frame?) |
78 | 155 | ||
156 | Let me list what I think needs doing: | ||
157 | |||
158 | 1) Better CI setup: build on multiple platforms, build of | ||
159 | "arbitrary" branches, reporting of regressions with | ||
160 | decent diagnostics (!) to developers (not the crap | ||
161 | Gitlab gives where I don't even easily get a stack | ||
162 | trace on a core dump). | ||
163 | 2) A culture of fixing "other people"'s bugs: test case failures, | ||
164 | portability issues, Mantis reports, all the non-sexy | ||
165 | stuff. Not the 'psycstore' was written by tg, so no | ||
166 | need for !tg to try to fix it, or the "I use sqlite, | ||
167 | why should I bother with postgres?"-crap I have heard | ||
168 | too often. | ||
169 | 3) Improving test cases: better code coverage, more corner | ||
170 | cases, complex deployment scenarios (NAT!), etc.; | ||
171 | less manual testing by hand, more writing automated | ||
172 | tests. | ||
173 | 4) There are also some bigger architectural changes ahead | ||
174 | that I have mentioned in other places. Without those, | ||
175 | we won't be able to serve non-expert users. So help | ||
176 | with those would be welcome, but in terms of _process_ | ||
177 | I think 1-3 is what matters. | ||
178 | |||
179 | Note that none of this really adds up to a "release policy". | ||
180 | |||
181 | |||
79 | V. Previous Versions | 182 | V. Previous Versions |
80 | ==================== | 183 | ==================== |
81 | (if we found some flaws in the solution, and we want to change the | 184 | (if we found some flaws in the solution, and we want to change the |