Re: [GNUnet-developers] documentation: Rewriting the Installation Handbook with a focus on simplicity and coverage

[Nils Gillmann]

Schanzenbach, Martin transcribed 4.8K bytes:
> TL;DR: There are no working binaries because there are not current/regular 
> releases. The handbook should not claim what we cannot deliver. There are 
> temporary mitigations, however, such as docker images that we could provide 
> with 0 overhead given modern CI. Finally, compiling from source is for devs 
> only and they should know what they are doing.
> 
> Long version:
> The reason why docker is a good choice is because of our "release strategy".
> GNUnet has not seen a release in ages.

It's just been almost 4 years, it's not that long.

> The current "binaries" (deb, rpm?) are too old to be used.

And that's our problem how? For the Operating System side it works.
It's the most recent version. Some OS package newer versions from git.
If users ask for it, the obvious reaction should be working towards
a release. In some OS I've notified them of changes and helped working
to improve the packages they maintain.

> So if user A comes to irc and asks "hey, how to I get the most recent, 
> working version?" the answer is:

So here's the thing... Why do we keep adding features to and not
concentrate on the couple of bugs that need to be fixed before we can
call it a new release?
From last July to December, and now almost again July we wanted to
get this done. Of course most (all?) of use are doing this in their
sparetime, and there's h2020, but we wouldn't have a discussion about
something like Docker. Grothoff told me (offlist) that the plan is to
move to release more often.
Docker is all around, everyone knows it, but it's no solution for everything.
Docker can be one option, not "hey, no releases and buiding from source is
too complicated, let's recommend Docker".

> 1. Don't use the binary packages (sic!)
> 2. Compile and install from git
> 
> The latter requires a lot of knowledge and takes time and effort. And then 
> you only have it installed along with a huge amount of dev dependencies the 
> software does not even need to run!

I don't think software installed that you don't need at runtime is no problem.

> Imagine user A comes to irc and asks the same question.
> The answer could be: "No release, yet. You could use a docker image for the 
> current upstream though. Then you just need to run $ docker run 
> gnunet:latest".
> (And this answer works regardless of OS)

I'm not lobbying for Guix or Nix, but if that's the gist of your
reply, we could maintain a Nix or Guix package because they also run
on a variety of OS. At this point I'd rather that Devan gives some feedback
about docker, since I don't think Docker should be our 'only' reply to
easy running software.

> Again, this is a result from our lack of releases. But thanks to things like 
> docker, we could still deliver nightly precompiled images.
> 
> The handbook should reflect this:
> 
> 1. The easy way (for users, docker image)
> 2. The hard way (for devs, from source)
> 3. The future way (binary packages/installer) (WIP!)
>
> Eventually this could be changed into:
> 
> 1. I just want to use it (binary packages/installer)
> 2. I want to develop! (from source)
> 3. Optional: Use docker image to run GNUnet without installing
> 
> 
> > On 4. Jun 2018, at 10:34, Nils Gillmann <address@hidden> wrote:
> > 
> > Nils Gillmann transcribed 693 bytes:
> >> Schanzenbach, Martin transcribed 10K bytes:
> >>> 
> >>> 
> >>>> On 3. Jun 2018, at 22:33, Nils Gillmann <address@hidden> wrote:
> >>>> 
> >>>> Hi,
> >>>> 
> >>>> Schanzenbach, Martin transcribed 6.5K bytes:
> >> 
> >>>> Ideally it works like this: identify package manager. Look at
> >>>> the command you need to run to install it. Done.
> >>> 
> >>> Well that first requires packages. I do not thing we are there yet so 
> >>> this part would be blank.
> >> 
> >> We are in a good number of Operating Systems. The number can still grow,
> >> but it's more than 3.
> >> 
> >> 
> >> 
> >> I'll reply to the rest later.
> > 
> > Okay.
> > 
> > While I think you missed the point or your understanding of Docker is 
> > incomplete,
> > here's another take on this:
> > 
> > traditionally the INSTALL file, which in GNU projects often turned into some
> > kind of boilerplate (at least from what I've read), contained the 
> > information
> > how to install a software.
> > I think what you were getting at, is website content.
> > 
> > I think here's how to split and how I will handle this:
> > 
> > * I will look at `INSTALL' in the repository and see if I can edit it or 
> > even have to
> > * Provide an extending document which outlines details for odd ways some 
> > Operating Systems
> >  which we document.
> >  Even Docker falls under 'Can be documented in small textfiles'.
> > * Remove the Installation Handbook. We don't really need it. Move its 
> > relevant content
> >  into the user handbook and other parts.
> > * 2019 -> let's write a good website which includes how to simply install 
> > GNUnet.
> > 
> > No one ever reported problems installing GNUnet in binary form. It was 
> > always about
> > how to run it, how to configure it, etc. The matter of configuration of 
> > compile time
> > options etc will be part of the developer handbook.
> > 
> > WDYT?
>