[GNUnet-developers] Towards a new formalized release policy

[xrs]

Hey GNUnet devs,

During the last secushare mumble, we were discussing the state of
releasing GNUnet. When we met in January, talking about a GNUnet
release being "near" , we were quite excited about the new release
being near. Two months later we suspect that not many of the things we
defined as prerequisites for a release are done. On the contrary,
everything is business as as usual. It feels like we just make changes
to the code instead of working on the quality of the existing one,
which is one of the aforementioned prerequisites.

We are not trying to point fingers, or blame anyone, as that would be
harmful and unproductive, as well as an illogical response to what we
see as the problem. We are all developers of this codebase, as well as
peers. Therefore we would like to make some suggestions on how we would
like to change this:

[a]- Establish a release process. There are several models for how
to achieve this, e.g. having a hybrid rolling release with more spaced
out "stable" releases. We think we should do this as quickly as
possible. A proposal document in the GNUnet repo will explain several
solution models and after a month of feedback (improvements,
pros/cons, ...) we choose based on consent. "Consent" meaning, "I can
live with this", not "I'm for this", which is a constructive way of
decision making.

[b]- We were thinking about some kind of contest: Who will fix the most
codesonar findings from those 985 still there. The winner gets a
surprise, when we will meet next time, maybe this summer in Décentrale.

[c]- Your ideas! We like all of you thing about what could be
supporting to finally reach this common goal.

cheers

xrs, t3ss and secushare devs

***********************************************************************
********************* 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?)

The problem for the GNUnet community stated here is how to evolve the
GNUnet team and code organization, so that developing code gets
attractive again and using GNUnet for testing purposes or even for some
little usecases becomes easier. In the current organizational model
bugs tend to accumulate until they are not managable or overwhelming,
however, it's clear, that every release candidate should be free from
known bugs. There is more. Devs and user need to feel progress to have
"Erfolgserlebnisse" (roughly: "sense of achievement") and recognition,
like a new release, a "product" they have contributed to, listing new
features with short description of amazing privacy preserving use cases.

A possible solution to this problem might be a new and lightweighted
release model with git. 

Release Models with git:

Option 1:
  * code organization and branching
    * master branch is release branch, tagged with different version
      numbers development occurs in little side branches
    * mature code resides in a staging branch for testing and quality
      management 
  * release process
    * development in little side branches
    * if code is mature, merge with staging branch and do testing,
    * static/dynamic analysis and code audits if checks are okay, merge
      with release branch and tag with new version number

Option 2:
  * code organization and branching
    * master branch is development branch
    * further development task can be done in other side branches
      for every release candidate exists a new branch called after the
      version number 
  * release process
    * development in master and side branches
    * if code of side branches is mature merge with master branch
    * if code in master branch is mature, create if not existant a new
    * release branch called after the new version number and merge with
      master 
    * in the release branch do testing, static/dynamic analysis
      and code audits 
    * if checks are okay, tag as release candidate

Option 3:
...

Option 1 and 2 are two flavours describe in 
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)

IV. Doing
=========
(who does what within which time frame?)

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.)

pgpGf6hGSHIUR.pgp
Description: Digitale Signatur von OpenPGP