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: Marcel Klehr
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Fri, 8 Feb 2019 17:41:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

I believe Mozilla also have a huge monorepo, but I agree: It's ugly in
every possible way.

On 08.02.19 15:08, address@hidden wrote:
> I agree with Martin here, I see no benefit in merging gtk in.
> Schanzenbach, Martin transcribed 4.6K bytes:
>> As an example: Look at how large projects like GNOME are developed.
>> Nobody would even dare to put _everything_ in a single repository. That 
>> would be preposterous.
>> The only project I could think of that takes such an approach is systemd.
>> I know that you grothoff despise this project especially and while I 
>> actually think they have VALID arguments in doing so, GNUnet does not.
>>
>>> On 8. Feb 2019, at 15:00, Schanzenbach, Martin <address@hidden> 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 <address@hidden> 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
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>
>
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers



reply via email to

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