From: Christian Grothoff Date: Fri, 30 Mar 2018 16:32:37 +0000 (+0200) Subject: comments on rP X-Git-Tag: v0.11.0pre66~131 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=d9c9f4dd2f61620d1848c8c32a36341ec1f1e41e;p=oweals%2Fgnunet.git comments on rP --- 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: * if checks are okay, tag as release candidate -Option 3: +Option 3: (What we really do right now) +* changes that are not expected/known to break anything go into master; + we may be wrong, better CI may allow us to detect breaking changes + before merges in the future (but we shall never fault anybody for + breaking stuff in master in non-obvious ways); +* experimental development happens in branches, created by individuals + or groups as they see fit. They are encouraged to merge often (if that + would not break anything) to avoid divergence and to detect issues from + a merge/rebase early. +* actual _release policy_: + - tests must pass + - no compiler warnings for -Wall + - acceptance tests (manual feature test) must succeed + - no known "release critical" bugs (where RC has no formal definition, + mostly we rather explicitly declare certain bugs as "not critical") + o buildbots are happy (if running) + o static analysis is happy (if available, false-positives => ignore) + o documentation is reasonably up-to-date + + reasonable test coverage (if too terrible => move subsystem to experimental?) + + texinfo (HTML+PDF) and doxygen happy? Ideally without warnings! + + nobody screaming bloody murder because of almost-completed features/bugfixes + almost ready to be merged? + Legend: -: absolutely mandatory; o: important; +: nice to have + ... Option 1 and 2 are two flavours describe in @@ -72,10 +95,90 @@ III. Concerns (of team members) (if there are concerns of team members, write them down here to later review) +I disagree that "bugs tend to accumulate until they are not managable". +The real issue is that neither writing testcases nor fixing bugs are +fun tasks volunteers like to do. As you write yourself: you want a +sense of achievement, recognition, "new features". So as long as that +is what you are motivated to do, you will not get stable, well-tested +code. I don't have a magic bullet to motivate you to write more tests, +or to improve existing tests. -CG + +I also disagree that releases have to be 'known bug free'. That bar is +way too high. However, there are obviously 'critical' bugs, but what +they are is another debate. But not all bugs are critical. Also, +I would distinguish between 'standard' and 'experimental' subsystems. +Experimental subsystems should build. They don't have to run, or do +anything useful. Not even tests have to pass for a release IMO. -CG + +Git is also not a "release model". Git is a software development +tool. But introducing branches in Git won't fix bugs. It also won't +improve test coverage. It won't test the code on a broad range of +platforms. It also doubt it will give you the recognition you crave. +More importantly, what you describe is already happening, and +partially has contributed to the problems. Bart kept his own CADET +hacks in his personal branch for years, hence without much feedback or +review. The SecuShare team kept their patches in their own branch, +hence revealing interesting failure modes when it was finally merged. +Martin kept some of his ABE-logic in his own branch (that one was +merged without me noticing major problems). Anyway, what you propose +as Option 1 is already largely done, except that certain CI tasks +simply cannot be productively done pre-merge right now (and I'm all +for improving that situation). -CG + +Finally, there is one last elephant with respect to branches and +merging that I would like you to consider. Given that GNUnet is highly +modular, you have largely benefited from the modular architecture and +been able to hack in your respective corners, unaffected by other +modules (modulo bugs in dependencies). That is great, and the desired +development mode. It has the critical advantage that bugs in modules +that nobody depends upon (auction, rps, social) can be in 'master' and +won't disturb anything. As most new development usually happens on the +leaves of the dependency graph, that is great. However, occasionally +there are architectural changes. Not of the type where the graph +changes, but where key API assumptions change. We recently had one for +the GNU Name System with the dropping of ".gnu". Before, CADET +changed the semantics and paramter for 'port'. In the future, CORE +will introduce protocol versioning. Whenever such a change happens, +it usually falls upon the person making that change to update +dependencies as well (or at least to work with people who hack on the +dependencies to coordinate the adjustments). That way, changing an +API for in-tree dependencies is a minor nuisance. However, if +branches exist, making sure that API changes do not break _any_ branch +somewhere is impractical. So at least at times where "major" API +rewrites are happening, it is important to minimize the number of +branches. -CG + + IV. Doing ========= (who does what within which time frame?) +Let me list what I think needs doing: + +1) Better CI setup: build on multiple platforms, build of + "arbitrary" branches, reporting of regressions with + decent diagnostics (!) to developers (not the crap + Gitlab gives where I don't even easily get a stack + trace on a core dump). +2) A culture of fixing "other people"'s bugs: test case failures, + portability issues, Mantis reports, all the non-sexy + stuff. Not the 'psycstore' was written by tg, so no + need for !tg to try to fix it, or the "I use sqlite, + why should I bother with postgres?"-crap I have heard + too often. +3) Improving test cases: better code coverage, more corner + cases, complex deployment scenarios (NAT!), etc.; + less manual testing by hand, more writing automated + tests. +4) There are also some bigger architectural changes ahead + that I have mentioned in other places. Without those, + we won't be able to serve non-expert users. So help + with those would be welcome, but in terms of _process_ + I think 1-3 is what matters. + +Note that none of this really adds up to a "release policy". + + V. Previous Versions ==================== (if we found some flaws in the solution, and we want to change the