[Top][All Lists]

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

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

From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Sun, 10 Feb 2019 11:59:48 +0100

> On 10. Feb 2019, at 11:14, Christian Grothoff <address@hidden> wrote:
> Signed PGP part
> 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 am talking about BB?

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

Yay, more flags!

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

You do integration testing of transport through... reclaim? oO
reclaim is so far up the hierarchy that you won't even know what is happening..

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

Because I do not want to compile everything all the time in my CI.

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

You mean dvn maybe? I don't really have access to anything that would allow me 
to do that.

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

See above, yay more flags. But this is actually a problem I have not thought 
through tbh. I do not know how GNUnet is supposed to "work" in this regard.
I release reclaim. It is supposed to do X.
How am I supposed to release this? As a plugin for GNUnet? As _part_ of GNUnet 
(i.e. I need to tell my users to install this completely unrelated beast which 
includes a social network and peer-to-peer file sharing)?
I mean, currently I provide an out-of-the-box client with a docker image that 
runs GNUnet in a configuration that is most sensible for reclaim.
But the architecture of gnunet actually calls more for a GNUnet "app" store for 
a platform (GNUnet core,transport,gns,cadet et al) with a bunch of apps (fs, 
social, reclaim).
Now, ideally I would work with packages in a reclaim installer, i.e.

- check if gnunet-core is installed, if not install
- check if gnunet-reclaim is installed, if not install
- profit.

I mean, what exactly do you expect a package maintainer to do? Have separate 
packages for fs/social/reclaim? One huge package that depends on everything?
If yes, then how would the build look like? Do they have to "fully" build 
gnunet 3 times and cherry pick binaries? Do they have separate the build by 
hand because we build everything or nothing?

> Happy hacking!
> Christian

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

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