{"thread":{"id":"59539","subject":"Video conference libification eng discussion, this Thursday 16:30 UTC","startedAt":"2023-04-04T17:15:37Z","lastAt":"2023-04-11T18:39:17Z","messageCount":2,"participants":["Emily Shaffer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"474790","messageId":"CAJoAoZ=q6ppzErzBT2VygdHbfhezYtFSkM3rLtt+gTvdSrLEHQ@mail.gmail.com","threadId":"59539","inReplyTo":null,"subject":"Video conference libification eng discussion, this Thursday 16:30 UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-04-04T17:14:47Z","receivedAt":"2023-04-04T17:15:37Z","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\nI'll reply to this mail tomorrow-ish with the topic we'll discuss\nduring the meeting, and I'll reply again 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 a day ahead of the\nmeeting.)\n - Session topic: <TBD>\n\n - Emily\n"},{"id":"475164","messageId":"CAJoAoZ=FqzODvRQdm9nQtq1wCaFo6sPduWAm2T78+MArddH4nA@mail.gmail.com","threadId":"59539","inReplyTo":"CAJoAoZ=q6ppzErzBT2VygdHbfhezYtFSkM3rLtt+gTvdSrLEHQ@mail.gmail.com","subject":"Re: Video conference libification eng discussion, this Thursday 16:30 UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-04-11T18:39:00Z","receivedAt":"2023-04-11T18:39:17Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"The notes from this session follow:\n\n\n - (asynchronous) What's cooking in libification?\n\n   - Patches we sent regarding libification\n\n- How to review coccinelle?\nhttps://lore.kernel.org/git/kl6l7cuycd3n.fsf@chooglen-macbookpro.roam.corp.google.com\n\n   - Patches for review related to the libification effort\n\n - (asynchronous) What happened in the past 1-2 weeks that interested\nparties or intermittent contributors need to know?\n\n - (asynchronous) Where are you stuck? What eng discussions do we want\nto have? (We'll choose a topic from this list a day ahead of the\nmeeting.)\n\n\n\n*   Emily: what's the least ugly way to move existing code into\n\"libified\" code? oldname\\_lib.[ch] in the top level? lib/oldname.[ch]?\nlib/oldname/oldname.[ch]? Something else?\n*   Emily/Calvin: How do we feel about\nhttps://github.com/rra/c-tap-harness/ ? (3)\n*   Calvin: Git-compat-util contains many necessary includes, macros,\nand inline functions used across all of git, so therefore any library\nmust include it. There are a couple of dependencies inside of it,\nhowever, that prevent libraries from compiling independently with it.\n(lots)\n\n - Session topic: git-compat-util\n\n\n\n*   Intros\n    *   Emily: TL git-core @ google\n    *   Jonathan: git-core @ google\n    *   Calvin: git-core @ google\n    *   Randall: Platform maintainer for NonStop\n    *   Cem: Interested in contributing to Git but haven't sent\nanything yet, hi 🙂 Curious to hear what's going on and hoping to help\n    *   Siddharth: visiting git-core for just Q2 (@ google)\n    *   Linus: 20%ing on git-core (@ google) - interested in libification stuff\n    *   Glen: git-core @ google\n*   Randall: Mostly concerned about licensing and whether libification\nwill change the licensing stuff\n    *   Emily: for now Google doesn't see a reason to try to relicense anything\n*   Calvin: Git-compat-util contains many necessary includes, macros,\nand inline functions used across all of git, so therefore any library\nmust include it. There are a couple of dependencies inside of it,\nhowever, that prevent libraries from compiling independently with it.\n    *   Everything includes git-compat-util.h. So we need\ngit-compat-util.h to either be not a catchall (like we did with\ncache.h), and should we libify git-compat-util dependencies?\n    *   There are some things that are explicitly compatibility\nrelated, like git\\_pread(). This is ifdef'd so we always have a pread\nimplementation. That implementation comes from wrapper.h, and\nwrapper.h/wrapper.c includes Lots Of Stuff :') including trace2 and\nusage\n    *   die() impl is pretty bad also\n    *   Jonathan: We could say that git-compat-util.h can't depend on\nanything else. For example, we can't die(). This might be good,\nbecause anything provided by the platform shouldn't be die()ing\n    *   Calvin: So that means we don't even want to define usage(),\ndie(), warn(), error() in git-compat-util.h. That kind of makes sense!\nBut some libraries want to use die() for now\n    *   Emily: yeah, but we need to refactor that out 🙂\n    *   Calvin: Probably that means we should figure out the error\nreturning design\n    *   Linus: Are there already circular dependencies here?\n    *   Emily: Does that mean we should build all the\neveryone-needs-it libraries into one binary, so they can depend on\neach other in a complicated way if they need to?\n    *   Calvin: That doesn't really help with trace2 dependency\n    *   Randall: Are we sure how the packaging is gonna happen? Is it\nstatic, dynamic, …?\n    *   Emily: Within Git codebase, not really that worried yet beyond\nmaking sure they CAN compile independently and unit test\n    *   Jonathan: So mostly focusing on \"can I compile this explicit\nsubset of .[ch] files and run unit tests on them\"\n    *   Randall: Similar experience with OpenSSL and they dll-ified\ntheir code. That had a lot of platform-specific pain. Please tell me\nif you're interested in dlls 🙂\n    *   Emily: As far as the trace2 stuff, I imagine most people\ncalling Git libraries from their code won't want to trace at all. So\nwe probably want to libify trace2 stuff \\*and\\* provide a stubbed\nversion of the API, since that's such a common use case\n    *   Calvin: Maybe it makes sense to build that tr2-noop lib right\ninto a large \"git-common-lib\"\n    *   Calvin: and we can put strbuf, string\\_list, hashmap, etc. in\nthere and we might even be able to leave some things stubbed in\ngit\\_compat\\_util.h….\n    *   Calvin: This combined with packaging everything together into\na common library actually sounds really appealing\n    *   Glen: Do we have a good idea of what everything that would be\nincluded into this common library is? How can we annotate what is and\nisn't part of it?\n    *   Randall: A lot of platform problems we have had in the past\nare coming from git-compat-util. I'm always worried about it, please\nbe careful with it 🙂\n    *   Calvin: Hoping to avoid touching anything that's got an #ifdef\nas a general rule\n    *   Randall: the atexit() code is a place to be careful for sure.\nAnd NonStop is trying to start using pthreads. So, yes, I'm very\nworried here.\n    *   Linus: Would it make sense to have some large \"standard\nlibrary\" file with no deps and start moving stuff into it?\n    *   Emily: I'm worried about that turning into a mega-header like\ncache.h (or git-compat-util.h)\n    *   Randall: I like cleaner containment than making things extremely broad\n"}]}