Hi, tl;dr: - Should we move towards a monolithic gnunet.git repo which includes gtk/secushare again? - Should we instead move optional components (conversation, reclaim, messenger) out of gnunet.git as extensions? - Is "messenger" a part of "secushare"?
Long version: I was wondering how "messenger" relates to "secushare". Some time ago we moved secushare and related components out of gnunet.git and into an extension repository [1]. Now, I do not think we have settled on an approach on how to handle our component structure. Some time ago I proposed to move most components out of gnunet.git into extension repos while grothoff argued that maybe we should even include gnunet-gtk in the main repo [2]. It is unclear in general when to use gnunet-ext and when to develop a component in-tree. I would like to take this opportunity to restart this discussion: Should we move secushare back into gnunet.git? (Is the secushare team even planning to maintain it?) Is messenger an alternative to secushare or should it be part of it? Should we move towards a more monolithic repo in general and merge secushare/gtk as well? I still have concerns with respect to packaging from a monolithic repository structure. A distribution may want to offer multiple gnunet packages for each component (reclaim, secushare, gtk) in oder to more efficiently handle dependencies. But this may be discouraged if we have a single repo as packaging becomes more tedious. Think monolithic texlive vs modular texlive packages (I think most distributions now have a modular package). OTOH, releasing tarballs for each component is also a pain for us as developers. We probably also should not too much conflate repository structure and packaging structure. A monolithic repository structure could still result in modular packaging. But that would require clear packaging guidelines (from US!). Also, source distributions (gentoo et al) always require the (full) source tree checkout even for a small component. A modular repository structure would make it a lot easier for distribution packaging in any case. I think I proposed a separation into a set of "core" gnunet service and extensions. But I am not so sure anymore if that is a good idea. For example, missing DHT block plugins of extensions in the "core" package would result in bad performance of the extension service (?). BR [1] https://git.gnunet.org/gnunet-secushare.git/ [2] https://lists.gnu.org/archive/html/gnunet-developers/2019-02/msg00002.html
signature.asc
Description: This is a digitally signed message part