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

[Victoria Dye <vdye@github.com>]

Vivan Garg wrote:

Hi Vivan, 

Sorry for the delay in re-reviewing! You've largely addressed my original
comments, so I only had a few follow-up questions/notes to add.

> +# In GSoC
> +
> +## Plan
> +
> +Plan
> +
> +The proposed idea of increasing "sparse-index" integrations may appear straightforward 
> +initially. However, after reviewing previous implementations, I have found that this 
> +idea can present unforeseen difficulties for some functions. For example, to enable 
> +"sparse-index," we must ensure that "sparse-checkout" is compatible with the target 
> +Git command. Achieving this compatibility requires modifying the original command 
> +logic, which can lead to other unanticipated issues. Therefore, I have incorporated 
> +additional steps in the plan, to the steps proposed by the community and mentors, 
> +outlined below to proactively address potential complications.
> +
> +1.	Conduct an investigation to determine if a Git command functions properly with 
> +    sparse-checkout. This step is estimated to take approximately 7-14 days.
> +
> +2.	Modify the logic of the Git command, if necessary, to ensure it functions 
> +    properly with sparse-checkout. Develop corresponding tests to validate the 
> +    modifications. This step is estimated to take approximately 7-14 days.

I'm guessing these two steps will be much shorter if the command is already
compatible with sparse-checkout (<7 days for step 1, and you could skip step
2 entirely)?

> +
> +3.	Add tests to t1092-sparse-checkout-compatibility.sh for the built-in, focusing 
> +    on what happens for paths outside of the sparse-checkout cone.
> +
> +4.	Disable the command_requires_full_index setting in the built-in and ensure 
> +    the tests pass.
> +
> +5.	If the tests do not pass, then alter the logic to work with the sparse index.
> +
> +6.	Add tests to check that a sparse index stays sparse.
> +
> +7.	Add performance tests to demonstrate speedup.
> +
> +8.	If any changes are made that affect the behavior of the Git command, update 
> +    the documentation accordingly. Note that such changes should be rare.
> +
> +Points 3-8 combined should take approximately 15-30 days.

Does this also account for the time _after_ submission to the mailing list?
Responding to review comments, iterating on changes, etc?

> +
> +To summarize, each integration will follow a similar schedule to the one outlined 
> +above. Therefore, without extending the timeline, we can expect to complete 2-3 i
> +ntegrations during the GSoC program period.
> +
> +Timeline 
> +
> +Determining the exact time arrangement for each integration is difficult, as there 
> +may be unforeseen challenges that arise during the process. However, based on my 
> +estimation, I anticipate that each integration will take approximately 1.5 - 2 months 
> +to complete, starting from May 29th. Please refer to the detailed breakdown of each 
> +step in the plan section for a more accurate estimate.
> +The proposed integration schedule is as follows:
> +
> +•	git describe
> +•	git write-tree
> +•	git diff-files

At this point, initial integrations for both 'git describe' [1] and 'git
diff-files' [2] have been submitted to the mailing list. To make your plan
more flexible/resilient to concurrent contributions, I think it'd be
reasonable to give a list of 5-6 commands you'll choose from to complete
your 2-3 planned integrations.

[1] https://lore.kernel.org/git/pull.1480.git.git.1679926829475.gitgitgadget@gmail.com/
[2] https://lore.kernel.org/git/20230322161820.3609-1-cheskaqiqi@gmail.com/

> +
> +This schedule is based on the order of difficulty outlined in GSoC 2023 Ideas.
> +
> +It's worth noting that each integration may require different amounts of time 
> +and attention, and modifications to the schedule may be necessary as I delve 
> +deeper into each command. Nevertheless, I am committed to delivering quality 
> +results within the given timeframe.
> +
> +In summary, I anticipate that each integration will take an average of 1.5 months, 
> +but I remain flexible and open to adjusting the schedule as needed to ensure the 
> +success of the project.
> +	
> +Availability
> +
> +I commit to responding to all communication daily and being available throughout 
> +the duration of the program. While I will be taking some summer courses at my 
> +university, I will not be enrolled in a typical full course load. As part of GSOC, 
> +I plan to commit to a medium-sized project of 175 hours. I have experience managing 
> +my time effectively while taking courses and working full-time internships in the 
> +past.
> +
> +The program is officially 16 weeks long. To ensure timely completion of the project, 
> +I plan to spend 8 hours per week until August 15th, which is when my semester ends. 
> +From August 16th until September 1st, I plan to dedicate 8 hours per day to the project. 
> +There are only three weeks during which I would prefer to focus on other things: 
> +June 23rd-30th (midterm week) and August 1st-15th (finals season). However, as I will be 
> +committing 8 hours per day following Aug 15th, it should be ample enough to make up for it.

Thanks for adding these availability details!

> +
> +I am confident that I will have ample time to complete the project within the allocated 
> +time frame. Additionally, I am hoping to continue working on the project even after 
> +GSOC ends, as there are several functions that need to be implemented.
> +