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 <mschanzenb...@posteo.de> > 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 <christ...@grothoff.org> 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 >> GNUnet-developers@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnunet-developers >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
