[Top][All Lists]

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

Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Sun, 10 Feb 2019 11:14:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2/10/19 10:06 AM, Schanzenbach, Martin wrote:
> Maybe let me wrap this up for now because I do not see a point in arguing 
> further and there does not seem to be consensus:
> From a GNUnet app/service developer perspective (i.e. not GNUnet core 
> services) I have made the experience that the use of proper tooling and 
> separation benefits the overall experience both for developer and user.
> If you are interested in what I mean, you can look at 
> The thing is that the core of this application still resides within the 
> GNUnet monolith (src/reclaim).
> This is a pain for the following reasons:
> - No working CI/Testing
> - If CI/Testing is working, it takes too f**ng long if I only want to test my 
> changes / work on this component

Why does your CI runner run unrelated tests? Can't you limit it to only
the subsystems you care about?

> - I do not need the other sources especially fs and social and they only 
> bloat the final result (the GNUnet binaries are around 70MB btw)

We could introduce a --disable-fs flag (and IIRC social requires
--enable-experimental already).

> - Development of other things in GNUnet (e.g. transport update, fs) should 
> not have an immediate effect on my development flow. But they have.

Transport: well, that's the integration testing, which IMO is important.

> - For deployments, I need a stable GNUnet base (this is why there is a 
> gnunet-docker in there that builds a lean GNUnet image ~70MB)

There the issue I see is more that today we work a bit aggressively on
master, instead of doing experiments on branches. But this has partially
to do with the CI not being setup to test branches (yet). Still, I don't
see why you could not simply work on a reclaim branch that derives from
a sufficiently stable GNUnet base -- that is, if your focus is on
"stable base" and not "integration with latest development".

> As such I will, as proposed, simply try to improve this for _myself_.
> If the move to proper infrastructure (which has been opposed)

I thought you and ng0 were in the process of doing the Gitlab setup?
Admittedly as a trial, but I don't see why you still have a problem here.

> and proper separation is not shared, I do not really have a problem with 
> moving the code I am working on out of the gnunet.git and into the gitlab 
> repo above.
> Since it is, like fs or social, a component that does not have any horizontal 
> or vertical (upwards) dependencies, this will not affect the status quo in 
> any way.
> Especially since the current "CI" doesn't even build and test most of this 
> (=reclaim).
> Doing this with social/fs/etc as well would have the benefit of allowing me 
> to create images which are even smaller and do not contain functionality that 
> reclaim does not need, but this does not seem to have consensus so I have no 
> solution for this atm.

--disable-FEATURE flats for configure where then src/ simply
doesn't enter certain subdirectories would certainly have my approval here.

Happy hacking!


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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