From: Patrick Steinhardt <ps@pks•im>
To: Arnav Bhate <bhatearnav@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: [GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state
Date: Fri, 4 Apr 2025 11:19:06 +0200 [thread overview]
Message-ID: <Z--kCrCnl3Zw4YG7@pks.im> (raw)
In-Reply-To: <bcdeb3cf-33a1-4553-897d-0bc09dc6a78d@gmail.com>
On Thu, Apr 03, 2025 at 08:56:45PM +0530, Arnav Bhate wrote:
> Patrick Steinhardt <ps@pks•im> writes:
> > On Wed, Apr 02, 2025 at 11:44:12PM +0530, Arnav Bhate wrote:
> >> ### Timeline
> >>
> >> #### Pre-GSoC (Until May 8)
> >>
> >> - Explore the codebase, identifying global variables and how they are
> >> used.
> >>
> >> - Start to identify suitable locations for global variables.
> >>
> >> #### Community Bonding Period (May 8 - June 1)
> >>
> >> - Interact with mentor, discussing best ways to refactor various
> >> variables and make a plan based on that.
> >>
> >> - If time is left, start coding early, as my summer break will have
> >> started.
> >>
> >> #### Coding Period (June 2 - August 25)
> >>
> >> - Modify functions to add an `struct repository` argument where they
> >> depend on `the_repository` and replace all occurences of it.
> >>
> >> - Move global variables to their new locations in various structs,
> >> and refactor functions that depend on them to use their new locations.
> >
> > In large-scale projects like these it typically makes sense to work in
> > batches. Instead of having three separate phases to "define the
> > problem", "develop the solution" and "deploy the improvement" I would
> > strongly encourage you to define and tie together smaller batches of
> > work.
>
> What I meant is, before coding started, I want to finalise all the new
> locations for the global variables with my mentor, then I would actually
> modify the code in batches, struct-by-struct. Are you suggesting that
> the new locations not be finalised beforehand, or are we misinterpreting
> each other?
The problem I see is that you only have one large "Coding Period". What
we would like to see though is that you define smaller, self-contained
batches of work that you can try to land individually, as well as an
estimation around how long each of these batches will take you to both
developend and land in Git itself.
Patrick
next prev parent reply other threads:[~2025-04-04 9:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 18:14 [GSoC PROPOSAL v1] Refactoring in order to reduce Git’s global state Arnav Bhate
2025-04-03 9:59 ` Patrick Steinhardt
2025-04-03 15:26 ` Arnav Bhate
2025-04-04 9:19 ` Patrick Steinhardt [this message]
2025-04-05 18:41 ` [GSoC PROPOSAL v2] " Arnav Bhate
-- strict thread matches above, loose matches on Subject: below --
2025-03-26 5:26 [GSOC] [PROPOSAL V1]: " Ayush Chandekar
2025-03-28 13:06 ` shejialuo
2025-03-29 9:54 ` Ayush Chandekar
2025-03-31 14:17 ` shejialuo
2025-03-31 15:04 ` Ayush Chandekar
2025-03-31 15:18 ` Ayush Chandekar
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z--kCrCnl3Zw4YG7@pks.im \
--to=ps@pks$(echo .)im \
--cc=bhatearnav@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox