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

[Schanzenbach, Martin]

> On 10. Feb 2019, at 11:59, Schanzenbach, Martin <address@hidden> wrote:
> 
> Signed PGP part
> 
> 
>> 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 
>>> https://gitlab.com/reclaimid.
>>> 
>>> 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/Makefile.am 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.
> Example:
> 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?
> 

I think it is actually quite valuable to look at it from this perspective. How 
can you expect a package maintainer to do this kind of separation if we cannot 
even decide on this (through separation of repos).
A user might one day think "I want a file sharing tool!". And install $ apt 
install gnunet
Some weeks later he learns about reclaim.
At this point is reclaim already installed? Is GNUnet meant to be one big 
collection of applications with a huge dependency list or is it meant to be 
cherry-picked?
If it is the latter, then our repository structure and development style does 
not reflect this and makes it impossible for package maintainers to get right 
(I am including us here).
If it is the former, then I'm sorry but I have to fundamentally question the 
architecture.

>> 
>> Happy hacking!
>> 
>> Christian
>> 
>> 
>> 
> 
> 
>

signature.asc
Description: Message signed with OpenPGP