I believe Mozilla also have a huge monorepo, but I agree: It's ugly in every possible way.
On 08.02.19 15:08, [email protected] 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers > > >> _______________________________________________ >> GNUnet-developers mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/gnunet-developers > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
