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). > 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. > 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. > 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. > 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. 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. > 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. > 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! > 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. Thanks, Christian.
