Patrick Steinhardt <ps@xxxxxx> writes: > On Wed, Apr 02, 2025 at 11:44:12PM +0530, Arnav Bhate wrote: > [snip] >> ## Proposed Plan >> >> - Identifying all occurences of `the_repository` and updating them to >> use a `struct repository` passed to the function. > > I think that might be overly ambituous :) After all we're talking about > ~3500 occurrences, and it won't be feasible to replace them all in the > couple of months. This is rather a multi-year project, and one that has > already been going on for quite a while. > >> - Identifying global variables that should be moved and identifying >> suitable locations, some could be moved directly into >> `struct repository`, some in its sub-structs that already exist and >> some in newly created sub-structs. > > Likewise, I would recommend to properly scope _which_ variables you want > to replace. There's a ton of global state, so you should try to limit > the project to a reasonable workload. I could do all the global variables in environment.c. I feel like that is doable. Once I am finished with that, I could start replacing the_repository. >> - Identifying and updating occurences of these variables to reference >> their new locations. >> >> It makes sense that all the variables need not be in the same struct, as >> separation would keep the codebase organised, and thus easier to >> maintain. It would also make it easier to introduce these changes >> systematically, as a group of related variables, combined together in a >> struct, could be introduced in a single patch series. >> >> ### 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? > Thanks! > > Patrick -- Regards, Arnav Bhate (He/Him)
