> On 2. Feb 2019, at 11:12, Christian Grothoff <[email protected]> wrote: > > Signed PGP part > 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!?? >
One other thing to this comment: This dependency hell is a result of the bad/horrible architectural design choice. It should have been avoided in the first place. And yes, a separation of gnunet-<service> and gnunet-<service>-gtk is perfectly reasonable. As I said, the build order does not matter. If we want to offer a "gnunet-util-gtk" package, so be it. The shared gtk implementations of subsystems is questionable anyway unless the "main" gtk UI allows some kind of plugin mechanism for services and does not hardcode them. > > 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/gnunet-developers >> > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
