Re: [RFC][PATCH] GSoC 2023 proposal: more sparse index integration

From: Vivan Garg <v.garg.work@gmail.com>
Date: Feb 26, 2023, 23:52 UTC
Message-ID: <CADupsJN1zLxokk+Nh9=W9gb7UPFrGaiOJj4FM7zp+u9psPkTnw@mail.gmail.com>
In-Reply-To: <5575804f-0918-fa7c-7af1-da2f4cf073f7@github.com>

> Please wrap your text to 72 (or up to 80) characters; doing that will make
> this much easier for reviewers to format their emails. I've re-wrapped lines
> I'm commenting on below.

I wrote it in Word, copied and pasted it, and then sent it to the mailing list. However, I will send a revised version that is properly formatted.

Show 14 quoted lines

> References to other sources (e.g. web links) are usually made with [<N>]
> footnotes. In this case, that might look something like:
>
> "
> Git 2.25.0 introduced a new experimental `git sparse-checkout` command,
> which simplified the existing feature and improved performance for large
> repositories. It allows users to restrict their working directory to only
> the files they care about, allowing them to ensure the developer workflow is
> as fast as possible while maintaining all the benefits of a monorepo. [1]
>
> [1]: https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/
> "
>
> Same goes for the other references you've included.

Actually, I had all of the titles in the word document as hyperlinks; I'll make this change for the reviewers on the mailing list, but do you recommend changing it in the final proposal I'm submitting to Google?

Show 11 quoted lines

> > +## Microproject
> > +
> > +t4121: modernize test style
> > +Status: ready to merge
>
> To expand on the point made by Ashutosh [1], this microproject is not yet
> tracked by Junio's "What's cooking" emails (most recent here: [2]), so it is
> not "ready to merge." "Under review" would be a more appropriate
> description.
> [1] https://lore.kernel.org/git/CACmM78QTptLOvNHs9oE2NNareSNDb+ydGFKr0VHuboCBWSZbSw@mail.gmail.com/
> [2] https://lore.kernel.org/git/xmqq1qmeyfps.fsf@gitster.g/

I only put that in as a placeholder because the status is likely to change by the time I submit my proposal. However, I'll change the placeholder to WIP.

Show 8 quoted lines

>
> > Integration with “mv”
> > Integration with “reset”
> > Integration with “sparse-checkout”
> > Integration with “clean”
> > Integration with “blame”
>
> Please include mailing list archive links to these series.

I also had these as hyperlinks. However, I will include the link here.

Show 13 quoted lines

> "Two commands per 175 hours" is what I characterized as "rough
> expectations," but the actual number of commands integrated for the project
> will vary based on the complexity of the commands chosen. In a proposal, I
> would expect an applicant present their own, more detailed reasoning around
> how long various parts of the project will take, rather than simply quoting
> my high-level estimate.
> I said that "I'd be willing to extend as far as Oct 2 (four weeks) if
> needed", but that's a general statement about my own availability and does
> not mean that I think such an extension is necessary in this case. The ~360
> hours you mention is too large a margin over the 175 hours allocated for the
> project to properly understand your planned availability. I would prefer a
> more precise breakdown of the time you actually intend to send on the
> project.

Is it sufficient to assign an approximate time I intend to devote to each step in my plan?

Thanks!