*********************************************************************** ********************* 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?) In the past it was sometimes unclear when and how the community would reach its next release. Members were lacking in orientation and felt demotivated. Another minor concern not yet analysed in depth was the expectation to show the public that the GNUnet project is still active and making progress. With an old release distributed by popular linux distributions it was hard to showcase people the GNUnet features and encourage to participate in the project. To show people how the GNUnet project is releasing its software we hereby document the current release model: * All main development (e.g. towards 0.12.x) continues on master. * Developers can continue to develop features in their own feature branches, but are encouraged to frequently merge into master (as long as they don't break the build) to avoid divergence and to detect issues from a merge/rebase early. * 0.11.x releases *must* be protocol-compatible to 0.11.0. So once master is NOT protocol-compatible to 0.11.0, development for 0.11.x must continue in an 0.11-branch where we only cherry-pick those changes from master that preserve protocol-compatibility. * 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); * 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") - Whenever API changes happen the person making that changes should update dependencies or at least work with people who hack on the dependencies to cooridnate the adjustments 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 For further information see: 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) 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 Your argument is good. Two or three of us thought that the problem is about missing releases which we feld demotivating. We thought, we were stucked somewhere. But as you state, it is us not doing the necessary work. What I still find useful is to document the release process. In consequence I changed the problem statement. -xrs 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 Thank you, I agree and changed it. -xrs 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 With resprect to changes kept in branches the reason why I personally keep changes back is because it takes very long for me to get something really working in C. Before that I either not worth it or I don't want to blame other before not being sure it's not my fault. Can we track branches? Can we write a little cronjob that checks for branches that are to long undercover with the aim to recommend the responsible person to merge soon? - xrs 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 Thank you for clarifying. I added the API aspect above. -xrs 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". We should thing and talk about point 2 and 3 more in depth with the question in mind, how to make this task more attractive for the community :-) 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.)