{"thread":{"id":"59864","subject":"Video conference libification eng discussion, this Thursday 17:00 UTC","startedAt":"2023-06-14T16:28:59Z","lastAt":"2023-06-15T18:33:20Z","messageCount":2,"participants":["Calvin Wan","Emily Shaffer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"478379","messageId":"CAFySSZB5AvP04fF+Uk4E6JovxQGQpU0eUXW3KjeMxffQHmm9Sw@mail.gmail.com","threadId":"59864","inReplyTo":null,"subject":"Video conference libification eng discussion, this Thursday 17:00 UTC","fromName":"Calvin Wan","fromEmail":"calvinwan@google.com","sentAt":"2023-06-14T16:28:39Z","receivedAt":"2023-06-14T16:28:59Z","isPatch":false,"sender":{"key":"calvinwan@google.com","avatar":"https://avatars.githubusercontent.com/u/92547554?v=4"},"body":"Hello folks,\n\nGoogle is hosting a standing engineering discussion about libifying\nGit, for contributors interested in participating in or hearing about\nthe progress of this effort. Expect this discussion to be free-form\nand casual - no powerpoints here!\n\nWe typically hold this meeting every Thursday at 10am Pacific (17:00\nUTC) via Google Meet.\n\nTo get an invite to the video conference and the notes document,\nplease reply to this email. Please also add points to the agenda\n(template follows) if you want to raise awareness of them.\n\nWe'll choose a topic to discuss at the beginning of the meeting, and\nI'll reply afterwards with the notes.\n\n*   (asynchronous) What's cooking in libification?\n    *   Patches we sent regarding libification\n    *   Patches for review related to the libification effort\n*   (asynchronous) What happened in the past 1-2 weeks that interested\nparties or intermittent contributors need to know?\n*   (asynchronous) Where are you stuck? What eng discussions do we\nwant to have? (We'll choose a topic from this list at the beginning of\nthe meeting.)\n*   Session topic: TBD\n"},{"id":"478445","messageId":"CAJoAoZ=pKx413d28Y_984AMA4WqC5WzbDLWZ0iJCCH4zgRTEcA@mail.gmail.com","threadId":"59864","inReplyTo":"CAFySSZB5AvP04fF+Uk4E6JovxQGQpU0eUXW3KjeMxffQHmm9Sw@mail.gmail.com","subject":"Re: Video conference libification eng discussion, this Thursday 17:00 UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-06-15T18:31:46Z","receivedAt":"2023-06-15T18:33:20Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Hi folks, the notes from today follow:\n\n*   (asynchronous) What's cooking in libification?\n    *   Patches we sent regarding libification\n        *   WIP v3 of unit test project plan is on list\n(https://lore.kernel.org/git/c7729b66a42b77dfe9ef61ba7c81e78e00b4021d.1686352386.git.steadmon@google.com/)\n    *   Patches for review related to the libification effort\n*   (asynchronous) What happened in the past 1-2 weeks that interested\nparties or intermittent contributors need to know?\n    *   [calvinwan] I stuck git-std-lib into Google's monorepo and\nbuilt it, Glen built his config patches on top of git-std-lib in\nGoogle's monorepo too, it works, we can call some stuff from our\ninternal VFS, so yay!\n    *   Patch available upstream Soon(™)\n*   (asynchronous) Where are you stuck? What eng discussions do we\nwant to have? (We'll choose a topic from this list at the beginning of\nthe meeting.)\n    *   (see calvin's topic below)\n*   [calvinwan] How should compatibility files interact with libraries\nin the Makefile? Most files in compat/ only have a dependency on\ngit-compat-util.h, but there are some files that have higher level\ndependencies. For example, on Linux, git-std-lib only needs\ncompat/strlcpy.c and compat/fopen.c. In the Makefile, COMPAT\\_OBJS\nalready exists and correctly contains the set of files, but also\ncontains compat/linux/procinfo.c and compat/qsort\\_s.c. Neither of\nthese files are necessary for git-std-lib and while qsort\\_s.c is a\nharmless inclusion, procinfo.c contains problematic trace2\ndependencies. Therefore if a user of git-std-lib attempts to call a\nproblematic function in procinfo.c, they would encounter build errors.\nUnder different build settings (eg. on different OSes), it is entirely\npossible that certain functions in git-std-lib would break and users\nwould have to supply their own implementation. To summarize the\nproblem, I would like to piggyback off existing Makefile logic for\ncompat files, but also ensure that no problematic files are included\nacross OSes.\n    *   Currently git-std-lib is a set of files by itself, compat\nlibrary is another set built by itself, link against it to make\ngit-std-lib run\n    *   How do we keep using correct compat libs, make it work across\nOS and build system boundaries, without including too much that breaks\nin libified world?\n    *   Config.mac.uname could take a flag for git-std-lib for linux,\nand we'd have to add another flag for every OS, and then do the same\nfor every other library, so doesn't scale very nicely.\n    *   Emily: should COMPAT\\_OBJS be split into smaller multiple sets?\n        *   Calvin: yeah basically\n    *   Emily: can we just not expose procinfo/qsort\\_s via that API\nboundary? Is it ok to include too much if it's not used?\n    *   Calvin: I'm worried about git-std-lib working on Linux and\nbreaking on another system because of the compat stuff not being\npopulated\n    *   Glen: I suspect we don't want to target all of COMPAT\\_OBJS -\nstuff like fsmonitor doesn't ever need to go into the std-lib. I think\nthat's the set of platform-specific stuff we need for the Git binary,\nso can we distinguish the set of platform-specific stuff that's needed\nfor the std lib?\n    *   Calvin: yes, but we'd have to do the same distinguishing for\nconfig, objstore, other libraries. And we'd have to do that across\neach OS.\n    *   Glen: but for platforms which don't implement the thing we\nwant, they'd already have to reimplement the library even to build\nnormal git?\n    *   E.g. for linux and darwin we can ship the compat stuff with\nthe git-std-lib and our users can use it; platforms that don't have\nthe impls will have the same problem they have today.\n    *   If we're correctly defining COMPAT\\_OBJS\\_LIB in the makefile\nthen there's not really any makefile modification that needs to happen\n    *   Emily: does git-std-lib + compat-lib cover 100% of business\nlogic libraries?\n    *   Calvin: but where does procinfo go, for example?\n    *   Glen: if procinfo is just useful for trace2, then we should\ninclude it with trace2, not with everything, right?\n    *   Calvin: for sake of argument, if it's needed in the config\nlibrary then it also has to be included by config library, right?\n    *   Glen: isn't it the same as other libification, that we are\nmoving implementations/dependencies closer to their sole user\nlibraries?\n    *   Emily: do we see any other problematic dependency chains? Or\nis it just this one? If it's just this one that might be ok?\n    *   Calvin: then I think this means we have a makefile where\ngit-std-lib only includes the bare minimum it needs; at some point\n    *   Emily: i think putting the platform-specific stuff into\ngit-std-lib keeps with the vision of git-std-lib being the \"one stop\nshop\" for building and running any other git lib, so it would be OK to\ninclude compat stuff not needed just to run git-std-lib code, as long\nas it doesn't have a dep on another git library (like procinfo does).\n    *   Randall: does the platform stuff remain in the standard git codebase?\n    *   Emily: everything stays in the git codebase and mailing list\nstuff and so on\n    *   Randall: is compat/ moving into the git-std-lib or staying\nwhere it is? Where will the platform stuff live?\n    *   Glen: git-std-lib is a .a that contains the code we think most\nlib users will need, and we'll build it from the same git tree that\nthe rest of the git code lives in\n    *   Randall: procinfo doesn't have any nonstop stuff there, it\nwould just be a stub for nonstop, want to make sure we can still make\nit work\n    *   Emily: procinfo leaves stubs if there's no platform-specific\nstuff, so we want to make sure that procinfo still leaves stubs on\ne.g. nonstop\n    *   Randall: yeah, and then i can make sure it still works once we\nhave a series\n\nOn Wed, Jun 14, 2023 at 9:29 AM Calvin Wan <calvinwan@google.com> wrote:\n>\n> Hello folks,\n>\n> Google is hosting a standing engineering discussion about libifying\n> Git, for contributors interested in participating in or hearing about\n> the progress of this effort. Expect this discussion to be free-form\n> and casual - no powerpoints here!\n>\n> We typically hold this meeting every Thursday at 10am Pacific (17:00\n> UTC) via Google Meet.\n>\n> To get an invite to the video conference and the notes document,\n> please reply to this email. Please also add points to the agenda\n> (template follows) if you want to raise awareness of them.\n>\n> We'll choose a topic to discuss at the beginning of the meeting, and\n> I'll reply afterwards with the notes.\n>\n> *   (asynchronous) What's cooking in libification?\n>     *   Patches we sent regarding libification\n>     *   Patches for review related to the libification effort\n> *   (asynchronous) What happened in the past 1-2 weeks that interested\n> parties or intermittent contributors need to know?\n> *   (asynchronous) Where are you stuck? What eng discussions do we\n> want to have? (We'll choose a topic from this list at the beginning of\n> the meeting.)\n> *   Session topic: TBD\n"}]}