gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Towards a new formalized release policy


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Towards a new formalized release policy
Date: Wed, 28 Mar 2018 07:05:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Hi xrs,

I guess I should briefly chime in here with my perspective:

1) Yes, in January things briefly looked like there might be some
velocity, but the usual work then came back for me (and I am sure most
of you), slowing things down to the usual crawl.  Several people had
talked to me about possibilities of funding in Dec/Jan as well, but none
of it happened (so far, and some possibilities turned into definitive
"no"s). I also was mistaken about how quickly CI/Web
site/documentation/bugfixes would happen. But, with an all-volunteer
crew, things naturally move very slowly.

2) As for the release _criteria_, I had proposed a few simple minimal
requirements everybody seemed to agree upon at the time: (1) passing
testcases, (2) no compiler warnings / serious issues found in static
analysis, (3) passes 'acceptance' test where we manually try key
features in the GUI(s).  I think I also had as highly desirable (4)
working/passing CI/BB and (5) new Web site with current documentation,
but I'm (in principle) willing to forgo those. Also, we can decide to
cut out subsystems (psyc, multicast, psycstore, etc.) if those do not
pass tests and nothing else depends upon them.  So if we get this, I'm
generally happy to 'make dist' a new TGZ, which is 'making a release'.

3) What you are discussing is more the *development* process.  We
already have branches.  We have seen how merging branches for a release
can create wonderful additional chaos and delays because the branch
worked for the dev, but not on other systems --- and merging 100 patches
from a branch (as usual with insufficient unit tests) then makes for fun
debugging when you actually want to get a release done.  So without
better CI and better tests, they can do about as much harm as good. I am
all for "do not break master" and "only commit new code that builds and
passes tests to master". That won't fix the strange existing/random-ish
test failures we do have for a while now. For that, it would take better
tests, and people with the time to write them, and write them well.
Today, we sometimes have bugfixes in a branch not backported to master,
or branches that have not been rebased to master lacking bugfixes from
master. Wonderful. As maintainer, it's hard enough for me to keep track
of mainline/master and my own branches/developments. I cannot also
manually cherry-pick bugfixes from branches, and so far *many*
developers have been really shitty at merging their branches in a timely
fashion (and by "timely", I can point to examples in the time range of
within a few years).

So please, do feel free to use branches, but more importantly, write
good tests, make sure they pass, and merge if they do. Also, do setup a
CI, make sure the CI runs the tests on a wide array of systems, make
sure master *passes* the tests, and _then_ we can impose a 'do not break
master' regime for commits.  DVN had a very detailed proposal for this,
which I very much like as a medium-term vision. But that doesn't help
unless (1) meaningful tests exist, and (2) they pass on diverse
platforms to begin with (and we cannot blame people for pushing code
that works on their system).

4) To end on a personal note, here is *my* current plan for what *I*
want to do:
a) survive my current cold;
b) survive the semester without unnecessarily killing students (i.e.
death from exposure to non-GUI tools);
c) get some urgent-ish Taler bugs fixed ASAP;
d) get the testcases for the "core" subsystems to pass on my system(s),
fix 'critical' SA issues and do 'acceptance' testing in April/May/June
e) then make release, possibly moving subsystems with non-passing tests
or too ugly code to "--enable-experimental" or something like that
f) focus my own hacking on new transport/core in new branch; make
_really_ frequent releases of 'master' whenever bugfixes are merged;
g) organize summer-event in CH.

And as always: if my help is needed elsewhere, do let me know.


Happy hacking!

Christian

On 03/28/2018 01:25 AM, xrs wrote:
> 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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]