On Sat, Mar 29, 2025 at 03:24:05PM +0530, Ayush Chandekar wrote: [snip] > > > One key challenge is determining which variables should be part of > > > `repo_settings` and which should remain separate. While working on the patch to > > > refactor access to `core.attributesfile`, I received feedback from Junio that not > > > all global variables should be blindly moved into the `repo_settings` struct. > > > This reinforced the need to carefully assess which variables belong in `repo_settings` > > > and which should be handled differently. > > > > > > > Yes, this is correct. I somehow think whether we should put this > > paragraph into Pre-GSoC part? I think that you have found this when > > adding a patch to remove one global variable. And thus by communicating > > with the community, you have further understood that the requirement and > > the detail of this project. > > Yep, since I encountered this while working on the patch, it fits well > in the Pre-GSoC section. > Moving it there would better show how I learned more about the > project's scope through > community feedback. > Yes, this is my intention. This represents your ability where you interact with the community and get feedback. And this is what we want to see. > > > > And in your plan, you should just say that we need to do this. Would > > this be better? > > > So, I should remove all the categorization stuff and just say that I > would focus on > each variable, discuss in the community whether it should belong in the struct > repo_settings/repo or not while sending patches? I think you should put the categorization stuff into after-GSoC part. Well, I don't think you could focus on _each_ variable. This is impossible for you to talk about the way for _each_ variable. I somehow think that you could just write the proposal about how to handle one or two global variables. You already touch one setting "core.attributesfile" right? You may just elaborate more in the proposal. > I felt that keeping it general might seem vague, but that's the nature > of the project. Every variable > is unique and would need a different approach and outlining the > approach of each variable > in the proposal is not very feasible, as these decisions need to > happen collaboratively through > discussions in the community. > Yes, so you could firstly give how you want to handle the global variables from top. And give some concrete examples to demonstrate your idea. > Should I still mention that once the project is complete, we could > consider structuring related > stuff if the community sees value in it. > You could, mention this in after GSoC part. > > > This plan is flexible and may be refined through multiple iterations as I receive > > > feedback from the community and reviewers. > > > > > > Timeline: > > > --------- > > > > > > Pre-GSOC: > > > (Until 8 May) > > > - Explore the codebase more, focusing on environment-related code paths. > > > - Document how each global variable is used and how it can be moved to > > > repository settings. > > > - Study Git’s Coding Guidelines and the Pro Git Book to align with best practices. > > > > > > ---------- > > > > > > Community Bonding: > > > (May 8 - June 1) > > > - Engage with mentors to discuss different environment variables, their > > > dependencies, and the best approach for refactoring. > > > - Finalize an implementation plan based on discussions. > > > - Since I will be on summer vacation, I can start coding early and make progress > > > on the project. > > > > > > ---------- > > > > > > Coding Period: > > > (June 2 - August 25) > > > - Refactor global variables, replacing them with repository-scoped > > > configurations. > > > - Modify function signatures to pass `struct repository` explicitly instead > > > of relying on `the_repository`. > > > - Categorize variables into specialized structs to improve modularity and > > > maintainability. > > > > As I have said, this is a high-risk task. Categorization needs many > > iterations. And we may do this after GSoC. > > Yep, will update that. > > Thanks for your review, again:) > > Ayush Thanks, Jialuo
