> 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. Thanks for re-reviewing!! > > 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)? Yep, you got that right! Perhaps I'll add an optional tag to step 2 to indicate that it isn't required for each command. > Does this also account for the time _after_ submission to the mailing list? > Responding to review comments, iterating on changes, etc? It does account for time to reiterate until it reaches a reasonable state (similar to my microproject [1], in the sense that even though it has not yet been merged, it has received one approval), after which I plan to start working on the next command and continue reviewing the patch for any minor changes that may be required. [1] https://lore.kernel.org/git/CACzddJrZ8YdJ72ng3UpMGN9CJx0qW1+fZfyi3q01z2487V8fxw@xxxxxxxxxxxxxx/T/#m792fa5cc6c77c5ccb114b488beb72c1ea6145e34 > 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. I will do that! I didn't realise integration for 'git describe' had begun until last week, when I began working on it. I believe I will have to abandon the work I did over the past week because someone else started working on it before me. However, I also feel that I might not be able to squeeze out enough time in the coming week to be able to start and push another command integration before the application deadline (Apr 4th). > > [1] https://lore.kernel.org/git/pull.1480.git.git.1679926829475.gitgitgadget@xxxxxxxxx/ > [2] https://lore.kernel.org/git/20230322161820.3609-1-cheskaqiqi@xxxxxxxxx/ > > > + > > +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. > > +
