{"thread":{"id":"59720","subject":"Video conference libification eng discussion, this Thursday 16:30 UTC","startedAt":"2023-05-09T21:08:53Z","lastAt":"2023-05-09T21:08:53Z","messageCount":1,"participants":["Emily Shaffer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"476929","messageId":"CAJoAoZmNsqhNkSv+B071S3r-hfMbZa_Sd-SJAT09-BeDbG9cRQ@mail.gmail.com","threadId":"59720","inReplyTo":null,"subject":"Video conference libification eng discussion, this Thursday 16:30 UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-05-09T21:08:35Z","receivedAt":"2023-05-09T21:08:53Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?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're hoping to hold this meeting every Thursday at 9:30am Pacific\n(16:30 UTC) 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 want\nto have? (We'll choose a topic from this list at the beginning of the\nmeeting.)\n - Session topic: <TBD>\n\nThe notes from last week follow - my bad for not getting them out sooner.\n\n - What's cooking in libification?\n   - Patches we sent regarding libification\n*   Strbuf cleanups (all except patch 7/7 has been merged):\nhttps://lore.kernel.org/git/CAFySSZAOqX0pESfJ-7bYg9iR2RDB9PL6sC4Kcvr\\_zitdQ1kD\\_g@mail.gmail.com/T/\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 - Where are you stuck? What eng discussions do we want to have?\n(We'll choose a topic from this list at the beginning of the meeting.)\n*   Calvin: cleaning up git-compat-util. Git-compat-util contains the following:\n    *   Includes for standard and external libraries\n    *   Includes for internal headers (wildmatch.h, banned.h)\n        *   Elijah: I've got a patch removing wildmatch.h - is Calvin\nalready working on it?\n            *   Calvin: Nope, please send, this is out of scope of\nwhat I was looking at so happy to see your patch removing it\n    *   Declarations for functions in usage.c, wrapper.c, and various\nother files\n    *   Conditionally defined includes, functions, variables, macros\n    *   Unconditionally defined includes, functions, variables, macros\n        *   Some of the macros are for allocing arrays. Alloc.h also\ncontains ALLOC\\_GROW and ALLOC\\_GROW\\_BY. Should those macros be moved\ninto a header file like alloc-ll.h or a common.h? I originally thought\nalloc-ll.h made a lot of sense, but then then are macros like\nCOPY\\_ARRAY and MOVE\\_ARRAY that wouldn’t fit in there\n            *   Emily: Would these 4 macros make sense in something\nlike array.h, instead of packed up with alloc? Does it help at all to\nseparate this way instead?\n            *   Jonathan: Deciding how to slice it is pretty\nsubjective, better to focus on what users need to include in order to\nuse the libraries..?\n            *   But then, moving stuff from usage/wrapper into their\nown headers might be a good idea.\n            *   Better to focus on \"we need to move it for $REASON\"\nthan for organizational purposes?\n            *   Randall: Historically, the purpose of\ngit-compat-util.h is to allow all the platform-specific stuff to be in\none place. If we're moving alloc stuff away from there, the alloc\nstuff is platform-specific, so it might add some complexity, right?\n            *   Calvin: alloc has #ifdef alloc\\_h, i'd like to leave\nthose platform-specific ifdef'd stuff in git-compat-util, but the\nunconditional platform-agnostic stuff might make more sense to stand\nalone and reduce the volume of git-compat-util.\n            *   Randall: Yes, having git-compat-util contain only\nplatform-dependent things.\n            *   Elijah: banned.h is maybe an exception, because it's\nrequired everywhere just like git-compat-util is…?\n            *   Calvin: see point below about git-common-header.h\n*   I want to lessen the scope of git-compat-util to the following\n    *   Includes for standard and external libraries\n    *   Conditionally defined includes, functions, variables, macros\n        *   Unconditionally defined includes that are directly used by\nconditional includes can still be left in here\n*   Which means the other items belong in different files. I propose:\n    *   common.h\n        *   Unconditionally defined includes, functions, variables, macros\n    *   usage.h, wrapper.h, etc.\n        *   Declarations for functions in usage.c, wrapper.c, and\nvarious other files\n    *   git-common-header.h\n        *   #include \"git-compat-util.h\"\n        *   #include \"usage.h\"\n        *   #include \"common.h\"\n        *   #include \"wrapper.h\"\n        *   #include \"banned.h\"\n        *   This will be included by all files instead of\ngit-compat-util.h (or we could and move git-compat-util.h to a\ndifferent file and rename this file to git-compat-util.h)\n        *   Elijah: is wrapper.h/usage.h really needed by everyone?\nOtherwise LGTM\n        *   Calvin: usage.h doesn't quite exist, proposing to create\nit and start to remove it\n        *   Jonathan: usage.h also has die()\n        *   Emily: +1\n*   Elijah: next series is basically ready to send, no more cache.h\n>:) moves all the header decls into relevant files instead, so there's\nnothing left.\n    *   …and there was much rejoicing\n*   Emily: Josh Steadmon will be joining us working on unit testing\ninto CI etc, looking forward to it\n    *   Randall: Can share how we run Git suite on NonStop if that's\nhelpful, since any libification stuff needs to work there\n    *   Emily: Good idea to take a look at Calvin's c-tap-harness RFC,\nseems like platform compatibility will be a decision point about how\nto make sure unit tests are working on \"exotic\" platforms\n        *   https://lore.kernel.org/git/20230427175007.902278-1-calvinwan@google.com/\n    *   Elijah: For c-tap-harness, if the unit tests are quite small,\nthen outputting \"test OK\" for every test becomes a performance\nbottleneck. Are we batching those test plan outputs somehow? Some\nother performance thing?\n        *   Emily: benefit of having a source fork is that we can fix it\n        *   Randall: c-tap-harness uses autoconf that's beyond what\nNonStop can support. Major issue for NonStop on other projects\n        *   Elijah: but if we're bringing it in as a source dep then\nwe don't use autoconf and we can just build it with make, right?\n        *   Randall: also isn't it in cpp? Will we be able to use it?\n        *   Calvin: I compiled it as C in the RFC so I think we will be ok\n        *   Randall: oh, yeah, it's C89 so it will be OK for us since\nwe guarantee C99\n        *   Calvin: no fork up on GH or something, but you should be\nable to apply those rfc patches to master and try it out\n"}]}