Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again

[Martin Schanzenbach]

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