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] GSoC 2023 proposal: more sparse index integration
Date: Sun, 26 Feb 2023 15:03:00 -0800	[thread overview]
Message-ID: <5575804f-0918-fa7c-7af1-da2f4cf073f7@github.com> (raw)
In-Reply-To: <20230226083347.80519-1-gvivan6@gmail.com>

Vivan Garg wrote:
> ## Synopsis

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.

> 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. 
> (Bring your monorepo down to size with sparse-checkout, Stolee).

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.
> +## 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/

> 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.

> During my discussion with Victoria, she informed me that given my
> commitment of 175 hours, it is expected that I will be able to fully
> integrate two commands with sparse index during the GSOC program. My plan
> is to evenly distribute the work for each command over the course of the
> program. I am confident that I can start the project early as I have
> already established communication with my mentors and familiarized myself
> with the related documentation, although my understanding may not be
> comprehensive.

"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.

> ## Availability
> 
> I will respond to all communication daily and will be available throughout
> the duration of the program. Although 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 175 hours. I have experience managing my
> time effectively while taking courses and working full-time internships in
> the past. My semester ends on August 15th, and I have no commitments for
> the following month, which allows me to continue working beyond the end of
> the semester. With the flexibility to extend the timeline of GSOC, I am
> confident that I will have ample time to complete the project. I have
> already discussed this with Victoria, the mentor for the project, and she
> has agreed to extend the deadline until October 2nd, if necessary. After
> August 15th, I will be able to work at least 8 hours per day, totaling
> ~360 hours of work until the October 2nd deadline. 
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 spend on the
project.

> # Some Credits to Myself
> 

[...]

> Victoria mentioned that I was the first person to express interest in the
> project this year, either directly or via the mailing list. 

I want to be extremely clear on this point: while you were the first to
reach out to me, I do not consider that a weighting factor as to who is
ultimately selected for the project. The application deadline is April 4
[3], and I acknowledge that not every potential applicant has the time
available right now to get an early start on preparing their application.
Most importantly, I _absolutely do not_ want your comment to discourage
others from applying.

[3] https://developers.google.com/open-source/gsoc/timeline


  parent reply	other threads:[~2023-02-26 23:04 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 [this message]
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
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=5575804f-0918-fa7c-7af1-da2f4cf073f7@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).