gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Mon, 11 Feb 2019 20:08:34 +0100


> On 11. Feb 2019, at 19:26, Christian Grothoff <address@hidden> wrote:
> 
> On 2/11/19 6:47 PM, Christian Grothoff wrote:
>> Am I missing an argument here?
> 
> Let me answer my own question (cooking is great...).
> 
> Actually, one good way I could see separating things is by
> responsibility boundary. I don't actually want to be responsible for
> SecuShare or Re:claim passing tests for a release. It's an annoying
> distraction. OTOH, at least for Re:claim, we do have a capable person
> who (I presume) wants to manage the release cycle. This is not so much
> about self-aggrandizing than simply someone taking charge. I don't see
> this for FS or conversation, so here it would simply be more work (hence
> I'm fighting this). But with Re:claim, it would decentralize things,
> make me have _less_ work. So while I think for users it would be better
> to keep Re:claim in, I think for development it might actually be
> beneficial at least for _me_ (and maybe Martin).
> 
> So this suggests a simpler "rule": *if* we have a capable person who
> *wants* to manage a separate Git and manage releases (for a reasonable
> time period, say at least the next 3 years), *then* spitting off the
> component (if reasonably self-contained, yada yada) is an option.
> 
> Similarly, I am actually thinking of (re)moving SecuShare from the main
> framework, mostly because it is not yet ready for 0.11.0.  And if the
> SecuShare people would pick that up, that would be great.
> 
> So what do you think about this idea of orienting it a bit more along
> _responsibility_ (for release) boundaries (while of course preserving
> coherent technical units)?
> 

While that is a good argument, it only partially addresses my concerns.
I fear that in the current state the user will be provided with packages that 
contain everything in gnunet.git.
Which will result in the following scenario:

User: I want to try reclaim! How to I do that Martin?
Martin: Well, here you install this thing.
User: Great what is it?
Martin: Well, actually it is mostly GNUnet, it's what I used to build reclaim!
User: Why do I have a p2p file sharing (!)  and voip service installed now?
Martin: ...
User: ... wtf

(I could make the same argument with Gtk if it were in gnunet.git but I 
actually had the above conversation before)

I know that your argument here is not "well the package maintainer will 
eventually do the right thing if we throw more documentation at him" and "we 
just need to add another configure flag to disable fs builds" but that is a 
patchwork approach to a fundamental (and im my opinion a bit flawed) 
"design"[1] choice.
My approach to fix this is separation which coincidentally would probably also 
break up most components into responsibility chunks (grothoff you would simply 
be in charge of multiple chunks, like me if I take e.g. GNS as well).
I thought this approach is just the way it should be because it provides all 
kinds of additional benefits (wrt CI/testing).
I do concede at this point, however, that it also brings with it a lot of 
problems and challenges.

[1] (The design of GNUnet is actually fine I am talking about the source/dev 
style; actually to double down: I think the monorepo contradicts GNUnet's 
pretty nice modular service-based architecture)

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]