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

[Schanzenbach, Martin]

Hi,

"Proper" CI is something I really miss atm. I am kind of used to gitlab-ci atm 
and it is really nice to work with and setup as it is docker based.

I further propose one other thing that is a low hanging fruit given a good CI 
system: Dockerize gnunet
A gnunet docker image that is continuously built and pushed to a registry will 
allow new users to try gnunet almost for free. Without the hassle of 
installation.
We could have a "gnunet" and "gnunet-experimental" image as well and upload 
them to the public registry.
I currently have a fedora-based Dockerfile committed, but ideally we would have 
it alpine-based.
Further, basic setup (e.g. gns-proxy) need to be addressed for this but it can 
come later.

In the future a gnunet-ui Docker image could be built on top of the base images 
that includes the web based UI (see GSoC project) that would make it even 
easier to use GNUnet.

This is my (more limited) vision that is actually completely independent of 
releases but needs good CI. If course, for stable images we need releases ;)

BR

> On 28. Mar 2018, at 07:05, Christian Grothoff <address@hidden> wrote:
> 
> 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.
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers


- Martin

GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

signature.asc
Description: Message signed with OpenPGP