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. > - 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. Thanks! Patrick
