On Mon, Sep 23, 2019 at 10:53 AM Jonathan Tan <jonathanta...@google.com> wrote: > > > Prospective mentors need to sign up on that site, and should propose a > > project they'd be willing to mentor.
Yeah, you are very welcome to sign up soon if you haven't already done so as I think the deadline is really soon. > > I'm happy to discuss possible projects if anybody has an idea but isn't > > sure how to develop it into a proposal. > > I'm new to Outreachy and programs like this, so does anyone have an > opinion on my draft proposal below? It does not have any immediate > user-facing benefit, but it does have a definite end point. No need for user-facing benefits. Refactoring or improving the code in other useful ways are very good subjects (as I already said in my reply to Emily and Dscho). > Also let me know if an Outreachy proposal should have more detail, etc. > > Refactor "git index-pack" logic into library code > > Currently, whenever any Git code needs a pack to be indexed, it > needs to spawn a new "git index-pack" process, passing command-line > arguments and communicating with it using file descriptors (standard > input and output), much like an end-user would if invoking "git > index-pack" directly. Refactor the pack indexing logic into library > code callable from other Git code, make "git index-pack" a thin > wrapper around that library code, and (to demonstrate that the > refactoring works) change fetch-pack.c to use the library code > instead of spawning the "git index-pack" process. > > This allows the pack indexing code to communicate with its callers > with the full power of C (structs, callbacks, etc.) instead of being > restricted to command-line arguments and file descriptors. It also > simplifies debugging in that there will no longer be 2 > inter-communicating processes to deal with, only 1. I think this is really great, both the idea and the description! No need for more details. Thanks, Christian.
