Hi Samuel, On Mon, Oct 28, 2024 at 9:07 AM Samuel Abraham <abrahamadekunle50@xxxxxxxxx> wrote: > > Hello Git Community, > I hope you are doing well. > > ## Introduction: > My name is Abraham Samuel, I am participating in the December 2024 > Outreachy internship program and > this is my proposal for the project "Finish adding os-version > capability to Git protocol v2". > > ## Contribution to the Git Community: > > I have participated in contributions to Git’s codebase after getting > accepted into the contribution phase in October 2024, working on what > I found doable and within my reach. Below is the list of my > contributions: > > - [PATCH v4] t7300-clean.sh: use test_path* helper functions for error logging. > > List thread: > https://lore.kernel.org/git/pull.1811.v4.git.1728498122419.gitgitgadget@xxxxxxxxx/ > > Status: merged into master > > Merge Commit: 77af53f56f100b49fdcf294f687b36064d16feca > > Description: The patch converted instances of “test - [def]” > in test cases to test_path_* functions to get error logs when the test > case fails when testing for the existence of a file or directory after > “git clean” or “git clean -d” is called as the case may be. > > > > - [PATCH v4] notes: teach the -e option to edit messages in the editor > > Status: integrated into Seen It looks like it has even been merged into 'next' and its status in the last "What's cooking in git.git ..." email is "Will merge to master?" It would be nice to give the branch name "sa/notes-edit" to make the topic easier to track. > List thread: > https://lore.kernel.org/git/pull.1817.git.1729296853800.gitgitgadget@xxxxxxxxx/ > > Description: The patch worked on a #leftover bit which added > the “-e” option to “git notes add” and “git notes append” subcommands > when the message is supplied with the -F and/or -m options. The patch > enables fine-tuning the message by invoking the user’s default editor > prefilling the message in the editor to allow editing the message to > the required taste before adding the note to the commit > > ## Project Overview: > This proposal outlines a plan to complete the work on the os-version capability > patch series for Git's protocol v2. Initially introduced in June 2024, > this feature intends to enhance > communication by allowing Git clients and servers to share their > operating system (OS) information. > The capability aims to provide metadata that can improve issues > diagnosis and enable statistical insights. > > This project will involve refining the original patch which already > started the process of adding this feature, > addressing Windows compatibility issues, and implementing > configuration options to customise how the OS is > shared. > > ## Intern objectives: > The key objectives of this project are; > 1. Finalize 'os-version' Capability: Modify the existing patch series > to meet community requirements and improve > functionality, ensuring compatibility with different OS environments. > 2. Add configuration options: Create options that allow users to: > - Share only the OS name by default (eg, "Linux", "Windows") > - Disable OS information sharing completely > - Include a more verbose OS version display using commands like > uname -srvm on Linux Making it possible to customize what is shared, for example something like "OS: Linux, Arch: x86_64" might be nice too. > 3. Fix Windows Compatibility: Review and resolve issues with the > current tests on Windows, ensuring full cross-platform > support > 4. Ensure Tests Coverage and Reliability: Create robust tests to > verify the feature's functionality across supported platforms, > incorporating community feedback to refine and improve the patch series. > > ## Approach and Methodology > 1. Analyze and retrieve the existing patch series: > - Retrieve patches from the Git mailing list > - Review the current code and community feedback to understand > necessary improvements and privacy concerns > > 2. Apply and test the patch on a new branch: > - Set up a new branch based on master to isolate the work on the > os-version feature > - Apply the patches and perform an initial round of tests to > determine specific errors and how to address them > > 3. Address Community concerns and implement improvements > - Implement feedback on sending only the OS name (eg, "Windows")by > default using uname or equivalent method on different OSes > - Add configuration options for users to adjust the level of > detail in OS information sharing > - Allow toggling the feature off for privacy or preference > - Ensure that configuration changes are well-documented and user-friendly > > 4. Resolve Windows Compatibility issues: > - Address current test failures on Windows, working closely with > community inputs to meet compatibility standards > - Modify any OS-specific code or test as needed, to work across environments > > 5. Develop and refine tests: > - Ensure the test case covers all functionality: OS name sharing, > version details and disabled state > - Conduct platform-specific tests on Linux, Windows and other > environments to confirm accuracy It might be nice to explain how you plan to test on different platforms. > - Incorporate feedback from mentors and the community to finalize > the feature's functionality and robustness. > > 6. Document the feature and prepare for submission: > - Write documentation and examples for configuring the os-version > capability, explaining options and use cases > - Prepare the final patch series, following Git's contribution > guidelines for submission to the Git mailing list > > ## Timeline > 1. Community Onboarding: (Week 1 -2): > Tasks: > - Retrieve patches and create a dedicated branch > - Study past discussions and understand the improvements required > - Set up blog post to write about internship experience > 2. Initial Testing and Patching (Week 3 - 4): > Tasks: > - Apply Patches > - Run Initial tests > - Identify current issues, especially Windows compatibility > 3. Implement OS version configuration option (Week 5 - 7): > Tasks: > - Add options for OS name, detailed OS version and disabled state > - submit the initial patch series to the Git mailing list for review > 4. Windows Compatibility (Week 8 - 9): > Tasks: > - Review, debug and resolve Windows-specific issues > - Perform cross-platform testing and verify functionality > 5. Test Expansion (Week 9 - 11): > Tasks: > - Write comprehensive tests for OS version capabilities. > - Integrate tests to cover each configuration option. > - Submit initial patches for tests to the Git mailing list > - Implement community feedback and reviews on submitted test patches > 6. Finalizing and Documentation:( Week 12 - 14): > Tasks: > - Finalize code based on community inputs > - Prepare final patch patch submission with full documentation > - Complete my blog on internship experience > > ## Availability: > I will be available to work for a minimum of 30 hours per week and I > am not currently > enrolled in any academic activities or have any jobs. > > ## Post Outreachy: > The Git community fosters proper and effective communication, > regardless of one’s level of experience. The patience, guidance and > explanation of technical concepts shown by community members are > wonderful and this has made me grow not just technically but also > behaviorally. Due to this, I plan to continue actively participating > the in Git community and be part next generation of those saddled with Nit: maybe s/part next/part of the next/ > sustaining this great project and preserving its legacy. > > ## Appreciation: > A special appreciation to everyone on the mailing list for reviewing > my patches, the mentorship and guidance > I am grateful to you all. Thanks, Christian.
