Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > It's not just about the number of lines, but things coming up in grep, > and now unique code really stands out (e.g. strbuf_add_void, should > probably be just added to the main strbuf.h if it's needed...), and of > course the cost of attention of eyeballing an already big series on the > ML & the churn every time we have updates. These are all valid concerns. > Overall I'm all for having this carved out in its own directory at a > cost of a bit more maintenance burden if it can be shared with libgit2 & > be a standalone library. Do you mean by "this" the reftable stuff as a whole, or only the duplicated support library part? If the latter is split out of what we import as our reftable/ directory, and stored in a separate directory that we do not have to import (because we have strbuf and other stuff) but other people may choose to use (because they may not have strbuf and other stuff), that may work. Also, if the contents of reftable/ directory wants a pluggable allocator, the main code can be written to call reftable_malloc (or whatever), with a thin shim to interface with us (i.e. reftable_malloc() would be implemented as a thin wrapper around xmalloc() for us) which is stored in a separate directory just for us to interface with the main reftable library. For libgit2, there will be a separate directory that uses a different implementation of reftable_malloc() that would let them plug their preferred allocator. An arrangement like that might work. I do not offhand know if that kind of overhead is worth the trouble or if there are better ways, though. > I am concerned that it seems this code can't be maintained in git.git by > anyone not willing to sign a contract with Google. It can be maintained in git.git; the trouble comes when they want to update us. I however suspect that, as the primary intended audience, it is hard to imagine that the reftable library as a standalone project will be successful without going through the usual reviews and testing in git.git. So even though there exists github.com/google/reftable repository, its contents may not matter very much in practice, unless they come here and beg for the change we make ourselves anyway. Perhaps I am being naive. I dunno. > I sent a tiny PR for > a typo fix at [1] and got directed to sign [2] before someone at Google > could look at it. I see brian raised this before in [3] but there wasn't > a reply to that point. > > Is there some summary of how this part of integrating it is supposed to > work going forward? Yeah, thanks for raising a good point. We definitely need to figure this part out. > At first glance that seems like a recipe for perma-forking this pretty > much from day one, i.e.: > > A. Upstream changes happen > B. We get a patch to the bundled library to this ML > ==> Google employees maintaining A can't even look at B > ==> Patch B can't be integrated into A > > 1. https://github.com/google/reftable/pull/2 > 2. https://cla.developers.google.com/about/google-individual > 3. https://lore.kernel.org/git/20200512233741.GB6605@xxxxxxxxxxxxxxxxxxxxxxxxx/
