Video conference libification eng discussion, this Thursday 16:30 UTC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello folks,

Google is hosting a standing engineering discussion about libifying
Git, for contributors interested in participating in or hearing about
the progress of this effort. Expect this discussion to be free-form
and casual - no powerpoints here!

We're hoping to hold this meeting every Thursday at 9:30am Pacific
(16:30 UTC) via Google Meet.

To get an invite to the video conference and the notes document,
please reply to this email. Please also add points to the agenda
(template follows) if you want to raise awareness of them.

We'll choose a topic to discuss at the beginning of the meeting, and
I'll reply afterwards with the notes.

 - (asynchronous) What's cooking in libification?
   - Patches we sent regarding libification
   - Patches for review related to the libification effort
 - (asynchronous) What happened in the past 1-2 weeks that interested
parties or intermittent contributors need to know?
 - (asynchronous) Where are you stuck? What eng discussions do we want
to have? (We'll choose a topic from this list at the beginning of the
meeting.)
 - Session topic: <TBD>

The notes from last week follow - my bad for not getting them out sooner.

 - What's cooking in libification?
   - Patches we sent regarding libification
*   Strbuf cleanups (all except patch 7/7 has been merged):
https://lore.kernel.org/git/CAFySSZAOqX0pESfJ-7bYg9iR2RDB9PL6sC4Kcvr\_zitdQ1kD\_g@xxxxxxxxxxxxxx/T/
   - Patches for review related to the libification effort
 - (asynchronous) What happened in the past 1-2 weeks that interested
parties or intermittent contributors need to know?
 - Where are you stuck? What eng discussions do we want to have?
(We'll choose a topic from this list at the beginning of the meeting.)
*   Calvin: cleaning up git-compat-util. Git-compat-util contains the following:
    *   Includes for standard and external libraries
    *   Includes for internal headers (wildmatch.h, banned.h)
        *   Elijah: I've got a patch removing wildmatch.h - is Calvin
already working on it?
            *   Calvin: Nope, please send, this is out of scope of
what I was looking at so happy to see your patch removing it
    *   Declarations for functions in usage.c, wrapper.c, and various
other files
    *   Conditionally defined includes, functions, variables, macros
    *   Unconditionally defined includes, functions, variables, macros
        *   Some of the macros are for allocing arrays. Alloc.h also
contains ALLOC\_GROW and ALLOC\_GROW\_BY. Should those macros be moved
into a header file like alloc-ll.h or a common.h? I originally thought
alloc-ll.h made a lot of sense, but then then are macros like
COPY\_ARRAY and MOVE\_ARRAY that wouldn’t fit in there
            *   Emily: Would these 4 macros make sense in something
like array.h, instead of packed up with alloc? Does it help at all to
separate this way instead?
            *   Jonathan: Deciding how to slice it is pretty
subjective, better to focus on what users need to include in order to
use the libraries..?
            *   But then, moving stuff from usage/wrapper into their
own headers might be a good idea.
            *   Better to focus on "we need to move it for $REASON"
than for organizational purposes?
            *   Randall: Historically, the purpose of
git-compat-util.h is to allow all the platform-specific stuff to be in
one place. If we're moving alloc stuff away from there, the alloc
stuff is platform-specific, so it might add some complexity, right?
            *   Calvin: alloc has #ifdef alloc\_h, i'd like to leave
those platform-specific ifdef'd stuff in git-compat-util, but the
unconditional platform-agnostic stuff might make more sense to stand
alone and reduce the volume of git-compat-util.
            *   Randall: Yes, having git-compat-util contain only
platform-dependent things.
            *   Elijah: banned.h is maybe an exception, because it's
required everywhere just like git-compat-util is…?
            *   Calvin: see point below about git-common-header.h
*   I want to lessen the scope of git-compat-util to the following
    *   Includes for standard and external libraries
    *   Conditionally defined includes, functions, variables, macros
        *   Unconditionally defined includes that are directly used by
conditional includes can still be left in here
*   Which means the other items belong in different files. I propose:
    *   common.h
        *   Unconditionally defined includes, functions, variables, macros
    *   usage.h, wrapper.h, etc.
        *   Declarations for functions in usage.c, wrapper.c, and
various other files
    *   git-common-header.h
        *   #include "git-compat-util.h"
        *   #include "usage.h"
        *   #include "common.h"
        *   #include "wrapper.h"
        *   #include "banned.h"
        *   This will be included by all files instead of
git-compat-util.h (or we could and move git-compat-util.h to a
different file and rename this file to git-compat-util.h)
        *   Elijah: is wrapper.h/usage.h really needed by everyone?
Otherwise LGTM
        *   Calvin: usage.h doesn't quite exist, proposing to create
it and start to remove it
        *   Jonathan: usage.h also has die()
        *   Emily: +1
*   Elijah: next series is basically ready to send, no more cache.h
>:) moves all the header decls into relevant files instead, so there's
nothing left.
    *   …and there was much rejoicing
*   Emily: Josh Steadmon will be joining us working on unit testing
into CI etc, looking forward to it
    *   Randall: Can share how we run Git suite on NonStop if that's
helpful, since any libification stuff needs to work there
    *   Emily: Good idea to take a look at Calvin's c-tap-harness RFC,
seems like platform compatibility will be a decision point about how
to make sure unit tests are working on "exotic" platforms
        *   https://lore.kernel.org/git/20230427175007.902278-1-calvinwan@xxxxxxxxxx/
    *   Elijah: For c-tap-harness, if the unit tests are quite small,
then outputting "test OK" for every test becomes a performance
bottleneck. Are we batching those test plan outputs somehow? Some
other performance thing?
        *   Emily: benefit of having a source fork is that we can fix it
        *   Randall: c-tap-harness uses autoconf that's beyond what
NonStop can support. Major issue for NonStop on other projects
        *   Elijah: but if we're bringing it in as a source dep then
we don't use autoconf and we can just build it with make, right?
        *   Randall: also isn't it in cpp? Will we be able to use it?
        *   Calvin: I compiled it as C in the RFC so I think we will be ok
        *   Randall: oh, yeah, it's C89 so it will be OK for us since
we guarantee C99
        *   Calvin: no fork up on GH or something, but you should be
able to apply those rfc patches to master and try it out




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux