> > 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. > Got it! > > 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. > Right, I can do that. > You already touch one setting "core.attributesfile" right? You may just > elaborate more in the proposal. > Yep! > > 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. > Alright, will do. I'll send a new iteration of the proposal soon. Thank you so much for your inputs:) Ayush On Mon, Mar 31, 2025 at 7:47 PM shejialuo <shejialuo@xxxxxxxxx> wrote: > > 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
