{"thread":{"id":"59493","subject":"Video conference libification eng discussion, this Thursday 16:30UTC","startedAt":"2023-03-28T22:40:46Z","lastAt":"2023-03-30T21:32:17Z","messageCount":2,"participants":["Emily Shaffer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"474383","messageId":"CAJoAoZ=KrnAWV3PpfBkYNs_KHFP5O2dVYOWY3jF=CM9+d89Dpg@mail.gmail.com","threadId":"59493","inReplyTo":null,"subject":"Video conference libification eng discussion, this Thursday 16:30UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-03-28T22:39:56Z","receivedAt":"2023-03-28T22:40:46Z","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\nThanks, and I'm looking forward to it!\n - Emily\n"},{"id":"474490","messageId":"CAJoAoZm7147oH9ECr=y+OXonK5WSgc9H0b95sF7BhKjMn+oMZg@mail.gmail.com","threadId":"59493","inReplyTo":"CAJoAoZ=KrnAWV3PpfBkYNs_KHFP5O2dVYOWY3jF=CM9+d89Dpg@mail.gmail.com","subject":"Re: Video conference libification eng discussion, this Thursday 16:30UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-03-30T21:31:59Z","receivedAt":"2023-03-30T21:32:17Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Tue, Mar 28, 2023 at 3:39 PM Emily Shaffer <nasamuffin@google.com> wrote:\n> I'll reply to this mail tomorrow-ish with the topic we'll discuss\n> during the meeting, and I'll reply again afterwards with the notes.\n\nThe notes follow:\n\n*   (asynchronous) What's cooking in libification?\n    *   Patches we sent regarding libification\n        *   Glen: Clean up config parsing:\nhttps://lore.kernel.org/git/pull.1463.v3.git.git.1680025914.gitgitgadget@gmail.com\n    *   Patches for review related to the libification effort\n        *   Ævar: Remove some implicit the\\_repository:\nhttps://lore.kernel.org/git/cover-v2-00.17-00000000000-20230328T110946Z-avarab@gmail.com\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 a day ahead of the\nmeeting.\n    *   Glen: I want to change the signature of config\\_fn\\_t, but I’m\nnot sure how ML will respond to such large scale changes. I might just\ntry it and send it anyway, but it will take time.\n    *   Calvin: I moved some functions from strbuf.c to abspath.c, but\nthen I noticed that functionally, abspath.c and path.c have\nnon-distinct boundaries between what they both do. I’m wondering if it\nmakes sense to combine both files. Also the functions defined in\nabspath.c have their declarations in cache.h whereas path.c has its\nfunctions defined in path.h. I think we should at least add abspath.h\nwith it included in cache.h to start reducing the size of cache.h.\n*   Intros (if needed)\n    *   Emily: TL of git-core at google\n    *   Taylor: lots of Git stuff for some time\n    *   Elijah: at Palantir, looking for more time to work on Git\nstuff but for now it's \\*mostly\\* free time\n    *   Glen: git-core at google\n    *   Calvin: git-core at google\n    *   Daniel: TPM for git-core at google\n    *   Siddharth: working at git-core team for just this quarter at 80% time\n*   Session topic: Calvin's topic - boundaries between abspath and\npath and whether to combine\n    *   Elijah: I did a series taking lots of these declarations out\nof cache.h and into abspath.h and path.h\n    *   Agree that the boundary is fuzzy, didn't try to fix it. Just\nmechanically moved based on whether the impl was in abspath.c or\npath.c. Might be useful for you to build on top of this series\n    *   Calvin: extra context: cache.h is a grab bag of functions\nimplemented in other various .c files.\n    *   Especially interested in discussing the boundary between these\ntwo. Should we merge them together since they're all path-related?\n    *   Within abspath.c we have stuff that's explicitly for absolute\nor real paths. But in path.c we tend to have both.\n    *   Log diving didn't make it clear why we made a distinction into abspath.c\n    *   Elijah: I was trying to guess whether anybody figured out the\nrationale for the split. My guess was that it was actually pretty much\nrandom 🙂\n    *   Elijah: Do either of them bring extra headers/reduce dep size\ncompared to the other one?\n    *   Glen: Python path libraries are split into path objects and\nos.Path which handles OS-specific stuff like resolving symlinks etc.\nIs that a more reasonable delineation between these two things? Would\ncreate more churn but ignoring that for the moment\n    *   Calvin: can look into it\n    *   Emily: does that delineation make sense when we don't have a path type?\n    *   Glen: You could consider strbuf + path-specific functions are\nmore like a \"path class\"... that might be too small though\n    *   Emily: are callers always using both? Are callers of abspath\nones that need a minimal set of dependencies?\n    *   Calvin: Does Elijah's patch manage to entirely remove cache.h\nfrom path.c?\n    *   Elijah: would have to check\n        *   Yes, i did manage to drop it from path.c eventually but I\nalso had to remove setup.c stuff into setup.h so path.c could include\nsetup.h instead\n    *   Glen: Check - do we know what \"success\" means for this discussion?\n    *   Calvin: What problems might we have, what questions need to be\nanswered about those two things? Doing cleanups like this in the\nfuture, what does that look like?\n    *   Emily: The fact that path.c relies on setup.h makes me wonder\nhow much of this is super low level utility stuff vs. how much is more\nsemantically high level/git-specific. That might be a place to split\ntoo\n*\n*   Elijah: Curious why Glen is trying to change the type? What's\nwrong with it as it is?\n    *   Glen: If we modify it a little bit then we don't have to keep\nglobal state. For example, \"the config line for the current value i'm\nreading\" requires global state because we don't have a way to send it\nto the config\\_fn\\_t callback\n    *   Glen: It'd be nice to change it… but we use it everywhere,\nright? Is it too big to change?\n    *   Elijah: Right but it gets rid of a global :) :) :)\n    *   Glen: That's useful feedback actually!\n    *   Emily: Probably should change it so we don't have to make\nlarge scale change every time we want to add some functionality to\nthat callback (e.g. run-command.h or hook.h)\n*   Glen: Did people find this discussion useful? Especially for\npeople outside of Google? Was this this useful/how you envisioned this\nmeeting? What is better?\n    *   Elijah: Wasn't sure how it would go, I was already in the\nmiddle of a bunch of cleanup and was excited for the chance to send\nthose patches and get review.\n    *   I think we maybe went a little long on the abspath/path stuff,\nthe discussion was useful but don't want to cut it off.\n    *   Taylor: Didn't have many expectations anyways, this seems like\nmostly a Google effort so I didn't have expectations. Did think it was\nuseful and interesting\n*   Glen: Next time can we talk about how to cope with cocci changes\ne.g. `Ævar: Remove some implicit the\\_repository:\nhttps://lore.kernel.org/git/cover-v2-00.17-00000000000-20230328T110946Z-avarab@gmail.com`?\nBoth Elijah and I weren't sure how to review this - is it well-written\ncoccinelle? Will it slow down the cocci check?\n    *   Taylor: Yeah it's tricky because it's already too expensive to\nrun during CI, so we might not even care that it's slowing down the\ncheck?\n    *   Glen: Would like to talk about it and see if we can establish\nsome norms on the ML - explicitly state whether we care if it's\nslower, etc.\n    *   Taylor: We have a bunch of pending cocci changes, it never\nquite seems right to land big changes like this. Would be nice to talk\nabout when to land these - is the beginning of the release cycle\nbetter? etc\n    *** Note - this conversation made it to the list at\nhttps://lore.kernel.org/git/kl6l7cuycd3n.fsf@chooglen-macbookpro.roam.corp.google.com/\n***\n"}]}