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

[Christian Grothoff]

Hi Martin,

I'm honestly not sure about your idea, but mostly because I totally
don't see where to draw the line, or whether it would help or hurt.
Maybe you have a great idea here, but I just see issues:

For example, is GNS part of GNUnet "core" or an application? What about
gnunet-dns2gns? Is ReclaimID part of GNS?

Similarly, Lynx's vision for SecuShare incluced file-sharing. How do you
manage such dependencies? It seems to be possible to split up the
sources into anywhere between 1 and 50 packages!

What do we do with gnunet-gtk? Already some people miss out on
gnunet-gtk because they don't get that it's a separate download. Do we
create a gnunet-fs with or without gtk? Do you then have to configure
and install
gnunet-core+gnunet-gtk-base+gnunet-conversation+gnunet-conversation-gtk
in that order? Or do we merge all gnunet-gtk stuff with gnunet-core
and/or the respective applications? But gnunet-gtk-common cannot even be
tested right now without some application.  Is splitting the sources
into 30+ sub-sources really going to make it _easier_ to install!??


My general feeling: it might be better to _reduce_ the number of
repositories, maybe merge gnunet-gtk.git with gnunet.git if we want to
make the installation _easier_.  End-users don't want to have to
download tons of repos with complex dependencies where they need to do
tons of steps in the right order.

Now, as for the *documentation*, that might be a very different thing.
There, I can very much imagine that we try to organize it better by
audience, and say
* this is for GNUnet core devs
* this is for ReclaimID users
* this is for secuShare users
* this is for GNS users

But even there, interdependencies between the modules and the need to
avoid duplication (and duplicated installation instructions means
inconsitencies when devs update one but not the other document) suggests
that keeping the documentation in one place would still be a good idea,
we just need to provide _clear_ entry points based on what the user
wants to do!


Anyway, that's just my impression from the support questions we've been
getting over the years (and from trying to get students to install
stuff). Fewer steps == better.  Splitting up the sources may _seem_ to
make the structure more obvious for developers, but people who are
already hacking on the code are not the ones with usability issues.

My 2 cents

Christian

On 2/2/19 9:07 AM, Schanzenbach, Martin wrote:
> Hi,
> 
> over the past few months that I have spent building and trying to 
> deploy/release GNUnet based software I was hit more than once by its 
> significant size and complexity.
> What I mean by that is beautifully illustrated by what I call myself the 
> "GNUnet Spaghetti Monster": https://stage.gnunet.org/en/architecture.html .
> In my opinion, this conflation of low-level functionality (transport, DHT, 
> crypto, utilities) and applications/services (secushare/social/psyc, voting, 
> conversation, fs, reclaim and maybe even gns) is detrimental to efficiently 
> manage a GNUnet "product".
> 
> My proposal: Either with 0.11 or beyond but definitely after TNG is done we 
> should strive to separate the apps wrt code but also presentation (e.g. 
> website).
> First, by having gnunet-ext [1] style repos for the apps.
> Weather a GNUnet app lives @gnunet.org or somewhere else shouldn't really 
> matter that way.
> 
> My hope is that this will significantly simplify the code and build of GNUnet 
> "base" and allow users/packagers to cleanly separate dependencies.
> We might run into app dependency and GNUnet base build dependency which might 
> not be trivial. Hence 0.11 is probably not feasible.
> 
> WDYT?
> 
> [1] https://gnunet.org/git/gnunet-ext.git/
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>

signature.asc
Description: OpenPGP digital signature