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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
