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

[Nils Gillmann]

Mike Mestnik transcribed 784 bytes:
> This is great, there are several issues I had working with GNUNet that
> existed entirely because there were no current releases.
> 
> There are a few things to consider above simply having regular releases and

I've had my doubts about this in the beginning (slow release cycles), but I
don't think it's bad. The expectation to release very frequent is nothing
new. And it exposes some weird "productivity" view on work.

Of course not having something like bi-anual releases is not good when
breaking changes are introduced. We should at least have a significant
portion of the network use the last stable release.

> that's handling changes that are incompatible with previous releases.  I
> would wager this will make LTS releases impracticable or impossible.

I think LTS without the S is possible, in theory old versions of the network
continue to work as long as people use them. They just need to be available
in the Operating System used as packages for downgrading, upgrading, etc).

But for support, I don't think we could manage supported LTS releases at this
point with a team this small and on volunteer time. It's something I see
worth doing (support for longterm versions of the network) when someone
comes up with an idea/rfc how this could work out for volunteers. I imagine
official "L"TS for ~12 months or something like that.

> Things to consider for a new release are API changes and of course protocol
> changes.  The project ideally would avoid making ABI changes while not
> making API changes.  I would hope that adopting release goals would make
> out of tree applications easy or easier to maintain.
> 
> ___
> GNUnet-developers mailing list
> GNUnet-developers@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

___
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

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