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

[Christian Grothoff]

On 2/11/19 8:08 PM, Schanzenbach, Martin wrote:
>> 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
> 

This only applies if they install from source (downstream didn't split
up the package), and if they had the optional dependencies (gstreamer,
etc.) installed (which your instructions would not have explicitly told
them to do), and if they actually noticed the file-sharing.  The latter
becomes much less likely if we do not launch it by default, which I
agree we should not.  Only downstream should enable it by default IF
they split the package and FS was explicitly installed.

So with the above, the only users that would even be in a position to
ask this question would be the once who manually hunted through their
file system to identify the purpose of a few 100-300k binary files.

And to that, I would have to say that whenever I go on such a hunt,
Debian gives me _plenty_ of 'wtf' moments where I wonder "where did X
come from!?"? ;-)

Still, as long as the additional code is not _running_ without the user
explicitly enabling it, I really don't think this is a big 'wtf'.

signature.asc
Description: OpenPGP digital signature