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: ng0
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Fri, 8 Feb 2019 14:08:30 +0000

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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