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

[Schanzenbach, Martin]

Well I proposed that we look at https://stage.gnunet.org/en/architecture.html 
(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).

Example:

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

BR

> 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 
>> REPO THEY INSTALL PACKAGES.
>> 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
>>>>> configure.ac 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
>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>> 
>> 
>> _______________________________________________
>> GNUnet-developers mailing list
>> 
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Message signed with OpenPGP