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 <t...@posteo.de> 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 <christ...@grothoff.org> >>> 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 >>> >>> GNUnet-developers@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnunet-developers >> >> >> _______________________________________________ >> GNUnet-developers mailing list >> >> GNUnet-developers@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
