On Tue, Oct 29, 2024 at 9:13 AM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > Hi, > > On Mon, Oct 28, 2024 at 10:27 AM Usman Akinyemi > <usmanakinyemi202@xxxxxxxxx> wrote: > > > Review the Current Patch Series > > -------------------------------------------- > > 1. Examine the Patch: Thoroughly analyze the existing patch series > > submitted to the Git mailing list. Understand its design and > > functionality, focusing on: > > - How the OS information is gathered and transmitted. > > - Current configurations and their implications on data transmission. > > 2. Feedback Analysis: Collect feedback from the Git mailing list > > discussion regarding the patch. Identify key concerns, especially > > related to: > > - Privacy issues. > > - Default behavior expectations. > > - Cross-platform compatibility. > > 3. Consider User-Agent Integration: Investigate the suggestion to > > integrate the 'os-version' data into the existing user-agent string > > rather than creating a new capability. Evaluate: > > - The implications of combining this data with the user-agent. > > - How this approach might address concerns about telemetry and user privacy. > > > > Implement Default Behavior for 'os-version' > > ---------------------------------------------------------- > > 1. Modify Default Configuration: Adjust the implementation so that by > > default, only the OS name (e.g., "Linux" or "Windows") is sent during > > communications. > > 2. Impact Assessment: Evaluate how this change impacts existing users > > and any potential performance implications. > > > > Introduce a Configuration Variable > > --------------------------------------------- > > 1. Define Configuration Options > > - Disable Option: Allow users to disable the 'os-version' > > capability entirely via configuration. > > - Verbose Option: Enable a verbose mode that sends detailed OS > > information (e.g., the output of the uname -srvm command). > > - Custom Option: Allows users to specify components independently, > > using variables such as $OS_NAME for OS, $DISTRO for Linux > > distribution, and $ARCH for architecture. > > For example: > > i. "OS: $OS_NAME, Distro: $DISTRO, Arch: $ARCH" might output "OS: > > Linux, Distro: Fedora, Arch: x86_64". > > ii. "Distro: $DISTRO Version, OS: $OS_NAME" could yield "Distro: > > Ubuntu 22.04, OS: Linux" > > Do you have ideas about how this configuration variable could be > named? An example of what the doc for it could look like? > > I haven't looked much into it, so I don't know what's best, but for a > custom option, an alternative to using $OS_NAME, $DISTRO, $ARCH, etc, > might be to use things like %(os_name), %(distro), %(arch), etc which > are used in ref-filter formats (see git for-each-ref documentation). > Hi Christian, I think going with the one in git for-each-ref is better for consistency across Git. > > 2. Documentation: Improve the documentation outlining how to enable, > > disable, and configure the 'os-version' capability. Include examples > > for: > > - Basic usage (default OS name). > > - Detailed usage (full OS version information). > > 3. Implementation: Code the configuration settings and ensure they are > > recognized by the Git system. > > > > Fix Cross-Platform Tests > > --------------------------------- > > > > 1. Identify Issues and added tests for changes/addition: Investigate > > existing test failures, particularly those occurring on Windows and . > > - Review the test logs and identify the root causes of failures. > > - Analyze differences in OS behaviors and how they affect the tests. > > - Cross-platform tests to validate the functionality on Linux, > > Windows, and macOS environments. > > It might be nice to explain how you plan to test on different platforms. Noted, I will do that. > > > 2. Implement Fixes: > > - Modify tests to ensure they run correctly on Windows, > > addressing any compatibility issues with the test framework or Git > > commands. > > - Ensure all tests reflect the changes made to the OS reporting > > capabilities. > > > > Testing and Validation > > ------------------------------ > > Ensure comprehensive test coverage—including default behavior, > > configuration options, and edge cases—integrate tests into the Git CI > > pipeline for automatic execution, and share results with the community > > for feedback on robustness and additional scenarios. > > > > Documentation Updates > > --------------------------------- > > > > 1. User Documentation: Update the Git documentation to include: > > - Instructions on how to configure the feature, with practical examples. > > - Best practices regarding data privacy when using the capability. > > 2 Developer Documentation: Include comments in the code for > > maintainability and understanding of how the 'os-version' capability > > works internally. > > > > Prepare for Merging > > ---------------------------- > > 1. Final Review: Conduct a thorough review of all code, tests, and > > documentation. Ensure everything aligns with Git’s contribution > > standards. > > 2. Engagement with Community: Present the finalized patch to the Git > > mailing list, addressing any additional concerns raised during the > > discussions. > > 3. Merge Process: Coordinate with the maintainers for merging the > > patch into the main branch, ensuring all feedback has been > > incorporated. > > > > > > —------------------------- Timeline —------------------------------------- > > > > Community Feedback and Finalization > > ============================= > > Dates: November 26 - December 8 > > Engage with the Git community to gather input, especially on privacy > > concerns and minimal data sharing. Determine default behavior (sharing > > only OS name) and finalize whether to use "user-agent" or another > > identifier in the protocol(os-version). > > > > Minimal Default Implementation > > ======================== > > Dates: December 9 - December 20 > > Implement the core feature to share only the OS name by default, > > keeping data minimal as per feedback. > > Send Patches for review from the Git community > > > > Configurable Options for OS Version > > ============================ > > > > Dates: December 21 - December 30 > > Develop settings to allow users to disable OS data sharing or choose > > verbose mode (e.g., uname -srvm output). > > Send Patches for review from the Git community > > My opinion is that disabling OS data sharing will be required from the > start, while choosing a verbose mode or a custom mode could be > developed afterwards. So I think steps like the following make more > sense: > > 1. Implement the core feature to share only the OS name by default, as > well as an option to disable that feature. > 2. Implement a verbose mode. > 3. Implement a custom mode. Noted, I will change that. > > > Cross-Platform Testing (Focus on Windows) > > ================================== > > > > Dates: December 31 - January 13 > > Conduct robust testing across platforms, addressing prior Windows > > compatibility issues. > > Send Patches for review from the Git community > > My opinion is that testing on all the platforms will be required for > each step, so that cannot be left for a later step. It should be > integrated into each of the development steps. Noted, I will make changes to that. > > > Beta Testing and Community Feedback > > ============================== > > Dates: January 14 - January 27 > > Release for beta testing, integrate feedback, and refine functionality > > based on real-world use. > > This should also be part of each of the development steps. Yeah. > > Also new features often spend some time in the 'next' branch before > being merged to master, which might be considered some kind of beta > testing, but we don't call it "beta testing". Before a new release is > tagged, we have a few rc0, rc1, etc releases, but they are not called > "beta" releases either. They are actually called "rc" releases, "rc" > meaning "Release Candidate". So overall, to avoid confusion, I think > it's better to not use the "beta testing" term unless you explicitly > say what you mean by it. > I will make use of rc here. > > Documentation > > ============ > > Dates: January 28 - February 10 > > Document feature usage, configuration options, and setup instructions > > for smooth adoption. > > Send Patches for review from the Git community > > Documentation should also be part of each of the development steps. Noted. > > > Final Review and Merge > > =================== > > Dates: February 11 - March 6 > > The final review phase will include presenting the completed work to > > the Git community for a thorough final assessment. Any remaining > > concerns or suggestions will be addressed before the patch is prepared > > for merge. This stage will allow for further feedback, particularly > > from stakeholders and maintainers who raised the initial questions, > > ensuring the solution is acceptable to the broad Git community. Once > > consensus is achieved, the patch will be merged into the Git mainline > > codebase, concluding the project. > > Not sure how things will go with reviews, but we prefer if development > can be incremental. So I hope some initial patches will be merged well > before the end of the internship. > > > Availability > > ======== > > I will be available to work for the required minimum of 40hours per week > > during the internship period and will be happy to extend if required. > > > > Blogging > > ======= > > I also plan to keep writing blogs after two weeks, to track my > > progress, give updates about what I am currently working on and also > > as a documentation for future contributors. > > > > Post Outreachy Internship > > ==================== > > One of my dreams is to be an active member of an open-source community > > which I can proudly support and contribute to. Continuing my > > contributions after the internship is a big part of making that dream > > a reality. I’m committed to contributing to Git long-term, helping to > > improve the project and supporting new contributors along the way. > > > > Appreciation > > ========== > > I really appreciate the support and guidance I got from the Git > > community. I also appreciate all the effort from the outreachy mentor. > > Thanks for your time. > > Thanks for your application! Thank you very much, I really appreciate the review. I will make the changes. > > > On Mon, Oct 28, 2024 at 9:09 AM Usman Akinyemi > > <usmanakinyemi202@xxxxxxxxx> wrote: > > > > > > On Mon, Oct 28, 2024 at 8:26 AM Christian Couder > > > <christian.couder@xxxxxxxxx> wrote: > > Please remove previous discussions you don't reply to at the bottom of > your emails. Noted. > > Thanks, > Christian.
