git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Victoria Dye <vdye@github.com>
To: Vivan Garg <gvivan6@gmail.com>, git@vger.kernel.org
Cc: christian.couder@gmail.com, hariom18599@gmail.com
Subject: Re: [RFC][PATCH v3] GSoC 2023 proposal: more sparse index integration
Date: Tue, 28 Mar 2023 09:20:57 -0700	[thread overview]
Message-ID: <bfd16069-e542-e8c2-e32e-b3e08fc27211@github.com> (raw)
In-Reply-To: <20230323063844.23222-1-gvivan6@gmail.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.
> +

  parent reply	other threads:[~2023-03-28 16:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-26  8:33 [RFC][PATCH] GSoC 2023 proposal: more sparse index integration Vivan Garg
2023-02-26  9:03 ` Ashutosh Pandey
2023-02-26 23:18   ` Vivan Garg
2023-02-26 23:03 ` Victoria Dye
2023-02-26 23:52   ` Vivan Garg
2023-02-27  0:46 ` [RFC][PATCH v2] " Vivan Garg
2023-03-23  6:38 ` [RFC][PATCH v3] " Vivan Garg
2023-03-23  6:50   ` Vivan Garg
2023-03-23 13:38     ` Derrick Stolee
2023-03-28 16:20   ` Victoria Dye [this message]
2023-03-28 17:54     ` Vivan Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bfd16069-e542-e8c2-e32e-b3e08fc27211@github.com \
    --to=vdye@github.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gvivan6@gmail.com \
    --cc=hariom18599@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).