[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: Sat, 9 Feb 2019 11:16:37 +0100

Well I proposed that we look at 
(which is not up to date currently).
IMO you can quickly identify which components are basically just applications 
that do not provide fundamental functionality (ie. what I referred to as 
"gnunet core"-- Note: this has nothing to do with the GNUnet core service).


- Secushare + social
- Conversation + speaker + microphone
- psyc + psycstore
- voting + secretsharing
- fs (+datastore)
- pt (not 100% sure what it does maybe it can stay in code depending on how 
niche the API is)
- reclaim (not in that architecture figure because its outdated)
- rest
- Gtk UI (already in separate repo)

I would argue that each of the above _could_ go into a separate repo for 2 
major reasons:

1. In the overwhelming case, they do not provide core functions to other 
services/apps (they do not have "incoming" arrows in the figure)
2. Often, they pull in unreasonable dependencies not required by any other 
component (rest: jansson, reclaim: libgabe, conversation: gstreamer etc)

As soon as a component does not fit into any of the above categories, it could 
be merged into the "core" repo again.


> On 8. Feb 2019, at 15:53, t3sserakt <address@hidden> wrote:
> Hey *,
> I also think it is better to have several repos. I can not tell how to split 
> up the gnunet.git repo, but we should not merge gnunet-gtk.git into 
> gnunet.git.
> cheers
> t3sserakt
> On 08.02.19 15:00, Schanzenbach, Martin wrote:
>> Yes, I do not think this is a good idea at all and is contrary to the 
>> initial motivation of this thread.
>> We already agree the from a user perspective, the packages (.deb/.rpm et al) 
>> should ideally be split into
>> the respective services/applications and, of course, also Gtk+. For sane 
>> dependency resolution at least.
>> But it is also reasonable to separate things at source level as I already 
>> gave various reasons, to which I have not heard a counterargument yet except:
>> Usability (???).
>> You cannot argue with usability because USERS DO NOT INSTALL FROM THE GIT 
>> And even the packages should be separate as you already agreed!
>> A monolith _will_ bite us when it comes to testing and CI.
>> Working on a single, huge codebase with a variety of build switches is a 
>> pain for testing, development and deployment.
>> Not to mention it is difficult to ascertain and ensure for an application 
>> what components are built.
>> Example: Do you really want to test everthing of the core gnunet functions 
>> if a Gtk widget changes?
>> Because that will inevitably happen.
>> It will be really difficult to setup a CI/automated testing that correctly 
>> separates this.
>> It will be possible, maybe, but then we have a test process that is equally 
>> difficult as our build process.
>>> On 8. Feb 2019, at 14:39, Christian Grothoff <address@hidden>
>>>  wrote:
>>> On 2/7/19 3:21 PM, Hartmut Goebel wrote:
>>>> Am 02.02.19 um 16:09 schrieb Christian Grothoff:
>>>>> And I wonder if it wouldn't make sense to have the gnunet.git
>>>>> test for Gtk+ and *if* libgtk is detected, _then_ build Gtk
>>>>> GUIs that are _included_ in gnunet.git, instead of requiring the user to
>>>>> download and configure yet another TGZ.
>>>> *If* the gui is merged into the main repo, I suggest adding
>>>> configure-options like `--without-gui`(which AFAIK is a autotools
>>>> standard thing) to avoid building the gui even if libgtk is detected.
>>>> This might happen if e.g. one is developing on her/his desktop.
>>> Sure, that makes sense. Any opinions from the silent masses on merging
>>> gnunet-gtk.git into gnunet.git and merging the source TGZs?
>>> _______________________________________________
>>> GNUnet-developers mailing list
>>> address@hidden
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden

Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

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