{"thread":{"id":"62413","subject":"[Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","startedAt":"2024-10-27T14:54:03Z","lastAt":"2024-10-29T11:51:01Z","messageCount":11,"participants":["Usman Akinyemi","Patrick Steinhardt","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"506153","messageId":"CAPSxiM-4okXfiWZtSNArMjfXzja9wBrMaEayhqt1hvJpu-PHkQ@mail.gmail.com","threadId":"62413","inReplyTo":null,"subject":"[Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-10-27T14:53:51Z","receivedAt":"2024-10-27T14:54:03Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"Hello Git Community,\n\nI hope this mail finds you well.\n\nThis is my proposal for the project \"Finish adding a 'os-version'\ncapability to Git protocol v2\" for Outreachy internship program 2024.\n\nI appreciate any feedback on this proposal.\n\n---------<8----------<8----------<8----------<8----------<8----------<8\n\nPersonal Information\n================\n\nFull Name: Usman Akinyemi\nEmail: usmanakinyemi202@gmail.com\nPersonal Blog: https://uniqueusman.hashnode.dev/\nPersonal Website: https://uniqueusman.tech\nGitHub: https://github.com/Unique-Usman\nDegree: Bachelor of Technology (B.Tech) in Computer Science and\nArtificial Intelligence\n\n\nAbout Me\n========\n\nI am Usman Akinyemi, I often like to refer to myself as a nomadic\ncomputer programmer as I love the ability to work on interesting\nprojects without being restricted to a physical location. I love the\nLinux Operating System and most people already alias my name to Linux\nas I also preach it to everyone everyday. I learnt programming in\nmultiple places, in college,  ALX Software Engineering program and\nalso personal studying. I have decent experience in contributing to\nOpenSource projects. I have contributed to systemd, Cpython\ndocumentation, Canonical website,  pep8speaks and Open Science\nInitiative for Perfusion Imaging (OSIPI). Being someone who is a\nproduct of the community, I value community development so much. I\nhave always tried my best to contribute to the community in my own\nway. One case is when I organized a month-long program(structured\nwebinar) aimed at exposing young Nigerians to opportunities in tech.\nThe program focuses on topics such as OpenSource contributions,\nsecuring internships, career development, freelancing, datascience,\nand introduction to Github and Linux([ Youtube Recording\n]https://www.youtube.com/watch?v=OrAThr-84t8&list=PLBW_HlYT-kP1tUqbzavMAq-ZZQRhMkZH2&ab_channel=UsmanAkinyemi\n). I have also volunteered for different communities one of which is\nDesignIT where we train Nigerian youth on technology.\n\n\nPast Experience with Git\n===================\nI have been a Git user for about three years now. I mainly use git for\npersonal projects, Group projects and OpenSource contributions. I have\nalso had the opportunity to introduce and teach people to Git. I am\nreally excited to be here in the Git community.\nDuring the contribution stage, I have got more familiar with the\ncommunity and how to send patches to Git with the help of the Git\ncommunity. I have also learnt a couple of things, one of which is Git\ncontributor best practices.\n\n\nContributions to the Git Community\n===========================\n\nI joined the Git community after I got selected for Outreachy\nContribution Phase and I have been able to send some patches to the\nGit codebase with the help of the Git community while also learning.\nBelow is the list of my contributions:\n\nMICROPROJECT\n------------------------\n- Link: https://public-inbox.org/git/pull.1805.git.git.1728192814.gitgitgadget@gmail.com/T/#u\n- Merge Commit: 6487b2b\n- Status: merged into next/jch\n\n+ [PATCH v7 1/2] t3404: avoid losing exit status with focus on `git\nshow` and `git cat-file`\n- Description: In the Git t3404 test script, I improved error\ndetection by restructuring command chains to ensure accurate exit\nstatus handling, preventing missed errors from piped commands.\nThe exit code of the preceding command in a pipe is disregarded. So if\nthat preceding command is a Git command that fails, the test would not\nfail. Instead, by saving the output of that Git command to a file, and\nremoving the pipe, we make sure the test will fail if that Git\ncommand fails. This particular patch focuses on all `git show` and\nsome instances of `git cat-file`.\n\n+ [PATCH v7 2/2] t3404: replace test with test_line_count()\n- Description: Refactor t3404 to replace instances of `test` with\n`test_line_count()` for checking line counts. This improves\nreadability and aligns with Git's current test practices.\n\n- Remarks: Through this process, I deepened my understanding of shell\nscripting and command chaining, focusing on how exit statuses affect\ntesting accuracy. My mentors suggested keeping commands readable and\nconsistent with Git's scripting standards, emphasizing simplicity and\nfuture maintainability. The result is a more robust, reliable test\nscript that better aligns with Git’s best practices, improving overall\ntest suite integrity. Also, through this patch, I was able to\nunderstand the workflow involved in submitting a patch to git which is\nquite different from many other projects which I have worked on. This\nis really an interesting learning experience.\nI also learnt about the importance of following Git’s best practices\nand also How  to submit patches with multiple commits.\n\nLeftOverbits\n-----------------\n- Link: https://public-inbox.org/git/pull.1810.v3.git.git.1729574624.gitgitgadget@gmail.com/T/#t\n- Merge Commit: cfd82c9\n- Status: merged into next/jch\n\nAfter completing the microproject, I wanted to gain a deeper\nunderstanding of Git’s codebase and workflow. I began looking through\nleftoverbits to work on and found a suitable one. Through this, I\nlearned how to add tests for my code additions, which helped me\nunderstand the process of integrating and validating changes in the\ncodebase.\n\n- General Description: In this series of patches, I replaced `atoi()`\nwith `strtoul_ui()` and `strtol_i()` across the daemon, merge, and\nIMAP components to address the issue of inadequate error handling and\ninput validation. The use of `atoi()` could lead to undefined behavior\nwhen parsing invalid inputs, such as letters, which might result in\nincorrect program behavior. Now, invalid inputs trigger clear error\nmessages, ensuring safer parsing and preventing malformed responses. I\nupdated tests for the daemon and merged components to verify these\nimprovements, while IMAP changes didn't include tests since none\nexisted for `git-imap-send`. Overall, this update significantly\nstrengthens input validation and code reliability.\n\n+ [PATCH v6 1/3] daemon: replace atoi() with strtoul_ui() and strtol_i()\nReplace atoi() with strtoul_ui() for --timeout and --init-timeout\n(non-negative integers) and with strtol_i() for --max-connections\n(signed integers). This improves error handling and input validation\nby detecting invalid values and providing clear error messages.\n\n+ [PATCH v6 2/3] merge: replace atoi() with strtol_i() for marker size\nvalidation\nReplace atoi() with strtol_i() for parsing conflict-marker-size to\nimprove error handling. Invalid values, such as those containing\nletters now trigger a clear error message.\n\n+ [PATCH v6 3/3] imap: replace atoi() with strtol_i() for UIDVALIDITY\nand UIDNEXT\nReplace unsafe uses of atoi() with strtol_i() to improve error handling\nwhen parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands.\nInvalid values, such as those with letters, now trigger error messages\nand prevent malformed status responses.\n\n- Remarks: In this patch series, I learnt a lot of things. The\nimportance of splitting large changes into Smaller changes for easy\nreview. I also learnt about how to submit multiple patches which are\nnot related by creating a new branch from origin/master. Also, I\nlearnt how to write better commit messages. And lastly, the importance\nof asking for help and integrating suggestions from the community.\n\nI also had the opportunity to review a patch and also answer doubt\nfrom other outreachy applicant mate\nhttps://public-inbox.org/git/CAEqABkKvbpo-8-gDpFtfNcpmiC8A5mJMkcDXfhcdNrpwMvBsDA@mail.gmail.com/T/#u\nhttps://public-inbox.org/git/CAPSxiM8SjJwb6x2bhCd4xsYLiNk+KhWYna7-rZhdNGpYNV1tLg@mail.gmail.com/\n\n\nPast experience with other communities\n===============================\n\nSystemd\n------------\n\n- I Developed a new unit test framework with assertion macros which\nenhanced debugging by providing detailed error reports with file\nnames, line numbers, and expression values upon failure, improving\nissue identification and resolution\n- I Updated approximately 22 existing unit test files by modifying 403\nlines of code to incorporate the new assertion macros, resulting in\nimproved logging details and enhanced overall test coverage and\ndebugging efficiency.\n- I Implemented the --json option for the bootctl status command and\nupdated the integration tests, enabling machine-readable JSON output\nfor comprehensive bootloader status information\n\nPR Link:\nhttps://github.com/systemd/systemd/pull/31873\nhttps://github.com/systemd/systemd/pull/31853\nhttps://github.com/systemd/systemd/pull/31819\nhttps://github.com/systemd/systemd/pull/31700\nhttps://github.com/systemd/systemd/pull/31678\nhttps://github.com/systemd/systemd/pull/31669\nhttps://github.com/systemd/systemd/pull/31666\nhttps://github.com/systemd/systemd/pull/32035\n\nPython Official Documentation\n-----------------------------------------\n- I have contributed to improving Python's official documentation,\nenhancing my Python knowledge, technical writing, and collaboration\nskills in open-source.\n\nPR Link:\nhttps://github.com/python/cpython/pull/109696\nhttps://github.com/python/cpython/pull/111574\nhttps://github.com/python/docs-community/pull/96\nhttps://github.com/python/cpython/pull/113209\nhttps://github.com/python/docs-community/pull/97\n\nOSIPI (Open Science Initiative for Perfusion Imaging(OSIPI) organization)\n---------------------------------------------------------------------------------------------------\n- Added a command-line interface to the existing 4D IVIM phantoms\ngenerator, with detailed documentation for usage.\n- Created a Python script for efficient reading and writing of NIfTI\nimages, improving data processing workflows.\n- Dockerized the TF2.4_IVIM-MRI_CodeCollection project and implemented\na GitHub Action for automated Docker image building and testing,\nensuring consistent deployment and a streamlined CI/CD pipeline.\n\nPR Link:\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/92a80d61cfca322da49d126dcd598996fca92668\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/163a187c5eaad33b55a0af0487bd9e19ca520828\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/56ee7173c91c7a1dd64412d3884a3167c7514665\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/e6a47211410ed57705e2ec32adb397ac6663d061\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/60\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/74\n\nCanonical Docs Website\n---------------------------------\nI developed a solution to integrate GitHub contributor information\ninto Sphinx documentation templates using the GitHub API, enhancing\ndocumentation with contributor insights.\n\nPR Link:\nhttps://github.com/canonical/sphinx-docs-starter-pack/pull/203#issuecomment-2018521984\n\nLLVM\n--------\nI fixed a bug in Clang's Extract API for Objective-C JSON generation\nand optimized the test suite within the LLVM Compiler Infrastructure.\nhttps://github.com/Unique-Usman/llvm-project/commit/32b53cf9d0c8c0e01ce5b0e7d5c717202a98cdf5\n\n\nExperience As a user of OpenSource Software\n====================================\n\nAs an avid user of open-source software, my experience has been\nprimarily with Linux distributions, particularly Arch, which serves as\nmy primary operating system. My past usage of Ubuntu has also\ncontributed to my understanding of different Linux environments.\nIn addition, I have extensively utilized various free software such as\nMySQL for database management, LibreOffice for office productivity,\nGCC and G++ for C and C++ programming, Python for scripting and\napplication development, React for web development, Clang for C/C++\ncompilation, Git for version control and many others. These\nexperiences have not only enriched my software knowledge but have also\ndeepened my understanding of the principles and benefits of\nopen-source development.\n\n\n—--------------------------------- Project Overview\n—--—--------------------------------\nIn June 2024, a patch series was submitted to the Git mailing list\naimed at adding a new 'os-version' capability to the Git protocol v2.\nThis capability is designed to allow Git clients and servers to\nexchange information about the Operating System (OS) they are using,\nwhich can aid in diagnosing issues and collecting statistical data.\nFollowing the patch submission, discussions arose regarding the\nnecessary improvements and issues, particularly with Windows\ncompatibility.\nThe objective of this internship is to address these outstanding\nissues, implement the required improvements, and ensure the successful\nintegration of the 'os-version' capability into the Git protocol.\n\n—------- Internship objectives and plans  —-------\nThe goal of this internship is to finalize the implementation of the\n'os-version' capability in Git protocol v2, as proposed in the patch\nseries sent to the Git mailing list in June 2024. This enhancement\nwill allow Git clients and servers to advertise their operating\nsystems (OS), aiding in diagnostics and data collection.\n\nDetailed Tasks and Steps\n====================\n\nReview the Current Patch Series\n--------------------------------------------\n1. Examine the Patch: Thoroughly analyze the existing patch series\nsubmitted to the Git mailing list. Understand its design and\nfunctionality, focusing on:\n   -  How the OS information is gathered and transmitted.\n   -  Current configurations and their implications on data transmission.\n2. Feedback Analysis: Collect feedback from the Git mailing list\ndiscussion regarding the patch. Identify key concerns, especially\nrelated to:\n    - Privacy issues.\n    - Default behavior expectations.\n    - Cross-platform compatibility.\n3. Consider User-Agent Integration: Investigate the suggestion to\nintegrate the 'os-version' data into the existing user-agent string\nrather than creating a new capability. Evaluate:\n    - The implications of combining this data with the user-agent.\n    - How this approach might address concerns about telemetry and user privacy.\n\nImplement Default Behavior for 'os-version'\n----------------------------------------------------------\n1. Modify Default Configuration: Adjust the implementation so that by\ndefault, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\ncommunications.\n2. Impact Assessment: Evaluate how this change impacts existing users\nand any potential performance implications.\n\nIntroduce a Configuration Variable\n---------------------------------------------\n1. Define Configuration Options\n    - Disable Option: Allow users to disable the 'os-version'\ncapability entirely via configuration.\n    - Verbose Option: Enable a verbose mode that sends detailed OS\ninformation (e.g., the output of the uname -srvm command).\n\n2. Documentation: Improve the documentation outlining how to enable,\ndisable, and configure the 'os-version' capability. Include examples\nfor:\n    - Basic usage (default OS name).\n    - Detailed usage (full OS version information).\n3. Implementation: Code the configuration settings and ensure they are\nrecognized by the Git system.\n\nFix Cross-Platform Tests\n---------------------------------\n\n1. Identify Issues and added tests for changes/addition: Investigate\nexisting test failures, particularly those occurring on Windows and .\n     - Review the test logs and identify the root causes of failures.\n     - Analyze differences in OS behaviors and how they affect the tests.\n     - Cross-platform tests to validate the functionality on Linux,\nWindows, and macOS environments.\n2. Implement Fixes:\n      - Modify tests to ensure they run correctly on Windows,\naddressing any compatibility issues with the test framework or Git\ncommands.\n      - Ensure all tests reflect the changes made to the OS reporting\ncapabilities.\n\nTesting and Validation\n------------------------------\nEnsure comprehensive test coverage—including default behavior,\nconfiguration options, and edge cases—integrate tests into the Git CI\npipeline for automatic execution, and share results with the community\nfor feedback on robustness and additional scenarios.\n\nDocumentation Updates\n---------------------------------\n\n1. User Documentation: Update the Git documentation to include:\n    - Instructions on how to configure the feature, with practical examples.\n    - Best practices regarding data privacy when using the capability.\n2 Developer Documentation: Include comments in the code for\nmaintainability and understanding of how the 'os-version' capability\nworks internally.\n\n Prepare for Merging\n----------------------------\n1. Final Review: Conduct a thorough review of all code, tests, and\ndocumentation. Ensure everything aligns with Git’s contribution\nstandards.\n2. Engagement with Community: Present the finalized patch to the Git\nmailing list, addressing any additional concerns raised during the\ndiscussions.\n3. Merge Process: Coordinate with the maintainers for merging the\npatch into the main branch, ensuring all feedback has been\nincorporated.\n\n\n—------------------------- Timeline —-------------------------------------\n\nCommunity Feedback and Finalization\n=============================\nDates: November 26 - December 8\nEngage with the Git community to gather input, especially on privacy\nconcerns and minimal data sharing. Determine default behavior (sharing\nonly OS name) and finalize whether to use \"user-agent\" or another\nidentifier in the protocol(os-version).\n\nMinimal Default Implementation\n========================\nDates: December 9 - December 20\nImplement the core feature to share only the OS name by default,\nkeeping data minimal as per feedback.\n\nConfigurable Options for OS Version\n============================\n\nDates: December 21 - December 30\nDevelop settings to allow users to disable OS data sharing or choose\nverbose mode (e.g., uname -srvm output).\n\nCross-Platform Testing (Focus on Windows)\n==================================\n\nDates: December 31 - January 13\nConduct robust testing across platforms, addressing prior Windows\ncompatibility issues.\n\nBeta Testing and Community Feedback\n==============================\nDates: January 14 - January 27\nRelease for beta testing, integrate feedback, and refine functionality\nbased on real-world use.\n\nDocumentation\n============\nDates: January 28 - February 10\nDocument feature usage, configuration options, and setup instructions\nfor smooth adoption.\n\nFinal Review and Merge\n===================\nDates: February 11 - March 6\nThe final review phase will include presenting the completed work to\nthe Git community for a thorough final assessment. Any remaining\nconcerns or suggestions will be addressed before the patch is prepared\nfor merge. This stage will allow for further feedback, particularly\nfrom stakeholders and maintainers who raised the initial questions,\nensuring the solution is acceptable to the broad Git community. Once\nconsensus is achieved, the patch will be merged into the Git mainline\ncodebase, concluding the project.\n\n\nAvailability\n========\nI will be available to work for the required minimum of 30 hours\nduring the internship period and will be happy to extend if required.\n\nBlogging\n=======\nI also plan to keep writing blogs after two weeks, to track my\nprogress,  give updates about what I am currently working on and also\nas a documentation for future contributors.\n\nPost Outreachy Internship\n====================\nOne of my dreams is to be an active member of an open-source community\nwhich I can proudly support and contribute to. Continuing my\ncontributions after the internship is a big part of making that dream\na reality. I’m committed to contributing to Git long-term, helping to\nimprove the project and supporting new contributors along the way.\n\nAppreciation\n==========\nI really appreciate the support and guidance I got from the git\ncommunity. I also appreciate all the effort from the outreachy mentor.\nThanks for your time.\n\nThank you.\nUsman Akinyemi.\n"},{"id":"506188","messageId":"CAPSxiM-YAAMwOvH8KYO+qKahCBHgw-NDb-eHJKNCZyk8xtpeGQ@mail.gmail.com","threadId":"62413","inReplyTo":"CAPSxiM-4okXfiWZtSNArMjfXzja9wBrMaEayhqt1hvJpu-PHkQ@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-10-28T01:56:36Z","receivedAt":"2024-10-28T01:56:48Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"Hello,\n\nAs I planned to submit a proposal for two projects, below is my\nproposal for \"Conversion of Git Unit Tests to Clar Testing Framework\".\nI would just go straight into the project proposals as the other\nnecessary information is in the previous email. I would prefer to work\non the \"Finish adding a 'os-version' capability to Git protocol v2\"\nproject in case.\n\nConversion of Git Unit Tests to Clar Testing Framework\n==========================================\n\nProject Overview\n-----------------------\n\nThis project aims to improve the Git codebase by migrating its unit\ntests to the Clar testing framework. Currently, Git employs a\nhomegrown unit testing framework located in t/unit-test/test-lib.h,\nwhich, while functional, leads to duplication and lacks extensibility.\nAdopting Clar, an established testing framework used in projects like\nlibgit2, will enhance test readability, reduce boilerplate code, and\nstreamline testing consistency across Git's unit tests. The migration\naligns with Git's quality standards, focusing on code maintainability\nand streamlined test management. The conversion was introduced by\nPatrick and it can be found in the public mailing list on\nhttps://lore.kernel.org/git/cover.1722415748.git.ps@pks.im/\n\nMotivation for Migration\n-------------------------------\n1. Avoid Duplication: Simplify test declaration by eliminating\nredundant test function wiring.\n2. Maintainability: Using Clar reduces the need for maintaining Git’s\ncustom testing framework.\n3. Extensibility: Clar can be extended easily with Git-specific\nfunctions, offering flexibility and scalability for future testing\nrequirements.\n4. Structured Execution: Clar provides a robust structure and\nefficient testing workflow, essential for a large project like Git.\n\nPhases, Timeline & Detailed Steps\n-----------------------------------------------\n\n---- December 9 - December 22: Preparation & Initial Conversions ----\n\n- Identify Target Tests: Begin by listing the .c test files from\nt/unit-tests that are suitable for conversion. Consult mentors for any\nspecific preferences.\n- First Test Conversion: Select a simple test file (e.g., t-hash.c)\nand convert it to the Clar format.\n- Initial Patch Submission: Submit the initial conversion patch to the\nmailing list for feedback. Document any unexpected obstacles and\nadjust methods accordingly.\n\n---- December 23 - February 10: Incremental Conversions & Feedback\nIntegration -----\n\n- File Renaming: Rename test files from t-<name>.c to <name>.c\nfollowing the structure outlined by prior contributions.\n- Clar Suite Integration: Add the module name to CLAR_TEST_SUITE in\nthe Makefile to include the file in the Clar testing suite.\n- Conversion of Test Assertions: Replace the test assertions with\nClar’s built-in functions (cl_assert, cl_assert_equal_s,\ncl_assert_equal_i, etc.), enhancing readability and functionality.\n-  Patch Submission: Submit each converted test as an incremental\npatch to Git's mailing list following the Git contribution guidelines.\nThis phased approach enables targeted feedback from the community.\n\nFebruary 11 - March 6: Final Conversions & Project Wrap-Up\n- Finalize Remaining Conversions: Complete the conversion of any\nremaining tests, focusing on consistency across all tests.\n- Validation of Converted Tests: Conduct thorough testing on each\nconverted file to confirm the expected behavior and functionality.\nAlso, ensure the test works perfectly well on all platforms(Linux,\nWindows and Mac)\n- Feedback Integration: Implement community feedback on the submitted\npatches, resubmitting as needed to finalize the converted files.\n- Documentation and Blog Updates: Maintain an ongoing blog,\ndocumenting progress, challenges, and insights from the conversion\nprocess, fostering transparency and community engagement.\n\nAdditional Goals and Extensions\n--------------------------------------------\n- Custom Assertions for Git-Specific Needs: Develop Git-specific\nassertion functions as needed for future tests.\n- Upstream Collaboration: Coordinate with Clar’s maintainers to\naddress any shortcomings discovered during integration with Git,\npotentially contributing back improvements.\n\n\nThank you for your time.\nUsman Akinyemi\n\nOn Sun, Oct 27, 2024 at 2:53 PM Usman Akinyemi\n<usmanakinyemi202@gmail.com> wrote:\n>\n> Hello Git Community,\n>\n> I hope this mail finds you well.\n>\n> This is my proposal for the project \"Finish adding a 'os-version'\n> capability to Git protocol v2\" for Outreachy internship program 2024.\n>\n> I appreciate any feedback on this proposal.\n>\n> ---------<8----------<8----------<8----------<8----------<8----------<8\n>\n> Personal Information\n> ================\n>\n> Full Name: Usman Akinyemi\n> Email: usmanakinyemi202@gmail.com\n> Personal Blog: https://uniqueusman.hashnode.dev/\n> Personal Website: https://uniqueusman.tech\n> GitHub: https://github.com/Unique-Usman\n> Degree: Bachelor of Technology (B.Tech) in Computer Science and\n> Artificial Intelligence\n>\n>\n> About Me\n> ========\n>\n> I am Usman Akinyemi, I often like to refer to myself as a nomadic\n> computer programmer as I love the ability to work on interesting\n> projects without being restricted to a physical location. I love the\n> Linux Operating System and most people already alias my name to Linux\n> as I also preach it to everyone everyday. I learnt programming in\n> multiple places, in college,  ALX Software Engineering program and\n> also personal studying. I have decent experience in contributing to\n> OpenSource projects. I have contributed to systemd, Cpython\n> documentation, Canonical website,  pep8speaks and Open Science\n> Initiative for Perfusion Imaging (OSIPI). Being someone who is a\n> product of the community, I value community development so much. I\n> have always tried my best to contribute to the community in my own\n> way. One case is when I organized a month-long program(structured\n> webinar) aimed at exposing young Nigerians to opportunities in tech.\n> The program focuses on topics such as OpenSource contributions,\n> securing internships, career development, freelancing, datascience,\n> and introduction to Github and Linux([ Youtube Recording\n> ]https://www.youtube.com/watch?v=OrAThr-84t8&list=PLBW_HlYT-kP1tUqbzavMAq-ZZQRhMkZH2&ab_channel=UsmanAkinyemi\n> ). I have also volunteered for different communities one of which is\n> DesignIT where we train Nigerian youth on technology.\n>\n>\n> Past Experience with Git\n> ===================\n> I have been a Git user for about three years now. I mainly use git for\n> personal projects, Group projects and OpenSource contributions. I have\n> also had the opportunity to introduce and teach people to Git. I am\n> really excited to be here in the Git community.\n> During the contribution stage, I have got more familiar with the\n> community and how to send patches to Git with the help of the Git\n> community. I have also learnt a couple of things, one of which is Git\n> contributor best practices.\n>\n>\n> Contributions to the Git Community\n> ===========================\n>\n> I joined the Git community after I got selected for Outreachy\n> Contribution Phase and I have been able to send some patches to the\n> Git codebase with the help of the Git community while also learning.\n> Below is the list of my contributions:\n>\n> MICROPROJECT\n> ------------------------\n> - Link: https://public-inbox.org/git/pull.1805.git.git.1728192814.gitgitgadget@gmail.com/T/#u\n> - Merge Commit: 6487b2b\n> - Status: merged into next/jch\n>\n> + [PATCH v7 1/2] t3404: avoid losing exit status with focus on `git\n> show` and `git cat-file`\n> - Description: In the Git t3404 test script, I improved error\n> detection by restructuring command chains to ensure accurate exit\n> status handling, preventing missed errors from piped commands.\n> The exit code of the preceding command in a pipe is disregarded. So if\n> that preceding command is a Git command that fails, the test would not\n> fail. Instead, by saving the output of that Git command to a file, and\n> removing the pipe, we make sure the test will fail if that Git\n> command fails. This particular patch focuses on all `git show` and\n> some instances of `git cat-file`.\n>\n> + [PATCH v7 2/2] t3404: replace test with test_line_count()\n> - Description: Refactor t3404 to replace instances of `test` with\n> `test_line_count()` for checking line counts. This improves\n> readability and aligns with Git's current test practices.\n>\n> - Remarks: Through this process, I deepened my understanding of shell\n> scripting and command chaining, focusing on how exit statuses affect\n> testing accuracy. My mentors suggested keeping commands readable and\n> consistent with Git's scripting standards, emphasizing simplicity and\n> future maintainability. The result is a more robust, reliable test\n> script that better aligns with Git’s best practices, improving overall\n> test suite integrity. Also, through this patch, I was able to\n> understand the workflow involved in submitting a patch to git which is\n> quite different from many other projects which I have worked on. This\n> is really an interesting learning experience.\n> I also learnt about the importance of following Git’s best practices\n> and also How  to submit patches with multiple commits.\n>\n> LeftOverbits\n> -----------------\n> - Link: https://public-inbox.org/git/pull.1810.v3.git.git.1729574624.gitgitgadget@gmail.com/T/#t\n> - Merge Commit: cfd82c9\n> - Status: merged into next/jch\n>\n> After completing the microproject, I wanted to gain a deeper\n> understanding of Git’s codebase and workflow. I began looking through\n> leftoverbits to work on and found a suitable one. Through this, I\n> learned how to add tests for my code additions, which helped me\n> understand the process of integrating and validating changes in the\n> codebase.\n>\n> - General Description: In this series of patches, I replaced `atoi()`\n> with `strtoul_ui()` and `strtol_i()` across the daemon, merge, and\n> IMAP components to address the issue of inadequate error handling and\n> input validation. The use of `atoi()` could lead to undefined behavior\n> when parsing invalid inputs, such as letters, which might result in\n> incorrect program behavior. Now, invalid inputs trigger clear error\n> messages, ensuring safer parsing and preventing malformed responses. I\n> updated tests for the daemon and merged components to verify these\n> improvements, while IMAP changes didn't include tests since none\n> existed for `git-imap-send`. Overall, this update significantly\n> strengthens input validation and code reliability.\n>\n> + [PATCH v6 1/3] daemon: replace atoi() with strtoul_ui() and strtol_i()\n> Replace atoi() with strtoul_ui() for --timeout and --init-timeout\n> (non-negative integers) and with strtol_i() for --max-connections\n> (signed integers). This improves error handling and input validation\n> by detecting invalid values and providing clear error messages.\n>\n> + [PATCH v6 2/3] merge: replace atoi() with strtol_i() for marker size\n> validation\n> Replace atoi() with strtol_i() for parsing conflict-marker-size to\n> improve error handling. Invalid values, such as those containing\n> letters now trigger a clear error message.\n>\n> + [PATCH v6 3/3] imap: replace atoi() with strtol_i() for UIDVALIDITY\n> and UIDNEXT\n> Replace unsafe uses of atoi() with strtol_i() to improve error handling\n> when parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands.\n> Invalid values, such as those with letters, now trigger error messages\n> and prevent malformed status responses.\n>\n> - Remarks: In this patch series, I learnt a lot of things. The\n> importance of splitting large changes into Smaller changes for easy\n> review. I also learnt about how to submit multiple patches which are\n> not related by creating a new branch from origin/master. Also, I\n> learnt how to write better commit messages. And lastly, the importance\n> of asking for help and integrating suggestions from the community.\n>\n> I also had the opportunity to review a patch and also answer doubt\n> from other outreachy applicant mate\n> https://public-inbox.org/git/CAEqABkKvbpo-8-gDpFtfNcpmiC8A5mJMkcDXfhcdNrpwMvBsDA@mail.gmail.com/T/#u\n> https://public-inbox.org/git/CAPSxiM8SjJwb6x2bhCd4xsYLiNk+KhWYna7-rZhdNGpYNV1tLg@mail.gmail.com/\n>\n>\n> Past experience with other communities\n> ===============================\n>\n> Systemd\n> ------------\n>\n> - I Developed a new unit test framework with assertion macros which\n> enhanced debugging by providing detailed error reports with file\n> names, line numbers, and expression values upon failure, improving\n> issue identification and resolution\n> - I Updated approximately 22 existing unit test files by modifying 403\n> lines of code to incorporate the new assertion macros, resulting in\n> improved logging details and enhanced overall test coverage and\n> debugging efficiency.\n> - I Implemented the --json option for the bootctl status command and\n> updated the integration tests, enabling machine-readable JSON output\n> for comprehensive bootloader status information\n>\n> PR Link:\n> https://github.com/systemd/systemd/pull/31873\n> https://github.com/systemd/systemd/pull/31853\n> https://github.com/systemd/systemd/pull/31819\n> https://github.com/systemd/systemd/pull/31700\n> https://github.com/systemd/systemd/pull/31678\n> https://github.com/systemd/systemd/pull/31669\n> https://github.com/systemd/systemd/pull/31666\n> https://github.com/systemd/systemd/pull/32035\n>\n> Python Official Documentation\n> -----------------------------------------\n> - I have contributed to improving Python's official documentation,\n> enhancing my Python knowledge, technical writing, and collaboration\n> skills in open-source.\n>\n> PR Link:\n> https://github.com/python/cpython/pull/109696\n> https://github.com/python/cpython/pull/111574\n> https://github.com/python/docs-community/pull/96\n> https://github.com/python/cpython/pull/113209\n> https://github.com/python/docs-community/pull/97\n>\n> OSIPI (Open Science Initiative for Perfusion Imaging(OSIPI) organization)\n> ---------------------------------------------------------------------------------------------------\n> - Added a command-line interface to the existing 4D IVIM phantoms\n> generator, with detailed documentation for usage.\n> - Created a Python script for efficient reading and writing of NIfTI\n> images, improving data processing workflows.\n> - Dockerized the TF2.4_IVIM-MRI_CodeCollection project and implemented\n> a GitHub Action for automated Docker image building and testing,\n> ensuring consistent deployment and a streamlined CI/CD pipeline.\n>\n> PR Link:\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/92a80d61cfca322da49d126dcd598996fca92668\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/163a187c5eaad33b55a0af0487bd9e19ca520828\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/56ee7173c91c7a1dd64412d3884a3167c7514665\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/e6a47211410ed57705e2ec32adb397ac6663d061\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/60\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/74\n>\n> Canonical Docs Website\n> ---------------------------------\n> I developed a solution to integrate GitHub contributor information\n> into Sphinx documentation templates using the GitHub API, enhancing\n> documentation with contributor insights.\n>\n> PR Link:\n> https://github.com/canonical/sphinx-docs-starter-pack/pull/203#issuecomment-2018521984\n>\n> LLVM\n> --------\n> I fixed a bug in Clang's Extract API for Objective-C JSON generation\n> and optimized the test suite within the LLVM Compiler Infrastructure.\n> https://github.com/Unique-Usman/llvm-project/commit/32b53cf9d0c8c0e01ce5b0e7d5c717202a98cdf5\n>\n>\n> Experience As a user of OpenSource Software\n> ====================================\n>\n> As an avid user of open-source software, my experience has been\n> primarily with Linux distributions, particularly Arch, which serves as\n> my primary operating system. My past usage of Ubuntu has also\n> contributed to my understanding of different Linux environments.\n> In addition, I have extensively utilized various free software such as\n> MySQL for database management, LibreOffice for office productivity,\n> GCC and G++ for C and C++ programming, Python for scripting and\n> application development, React for web development, Clang for C/C++\n> compilation, Git for version control and many others. These\n> experiences have not only enriched my software knowledge but have also\n> deepened my understanding of the principles and benefits of\n> open-source development.\n>\n>\n> —--------------------------------- Project Overview\n> —--—--------------------------------\n> In June 2024, a patch series was submitted to the Git mailing list\n> aimed at adding a new 'os-version' capability to the Git protocol v2.\n> This capability is designed to allow Git clients and servers to\n> exchange information about the Operating System (OS) they are using,\n> which can aid in diagnosing issues and collecting statistical data.\n> Following the patch submission, discussions arose regarding the\n> necessary improvements and issues, particularly with Windows\n> compatibility.\n> The objective of this internship is to address these outstanding\n> issues, implement the required improvements, and ensure the successful\n> integration of the 'os-version' capability into the Git protocol.\n>\n> —------- Internship objectives and plans  —-------\n> The goal of this internship is to finalize the implementation of the\n> 'os-version' capability in Git protocol v2, as proposed in the patch\n> series sent to the Git mailing list in June 2024. This enhancement\n> will allow Git clients and servers to advertise their operating\n> systems (OS), aiding in diagnostics and data collection.\n>\n> Detailed Tasks and Steps\n> ====================\n>\n> Review the Current Patch Series\n> --------------------------------------------\n> 1. Examine the Patch: Thoroughly analyze the existing patch series\n> submitted to the Git mailing list. Understand its design and\n> functionality, focusing on:\n>    -  How the OS information is gathered and transmitted.\n>    -  Current configurations and their implications on data transmission.\n> 2. Feedback Analysis: Collect feedback from the Git mailing list\n> discussion regarding the patch. Identify key concerns, especially\n> related to:\n>     - Privacy issues.\n>     - Default behavior expectations.\n>     - Cross-platform compatibility.\n> 3. Consider User-Agent Integration: Investigate the suggestion to\n> integrate the 'os-version' data into the existing user-agent string\n> rather than creating a new capability. Evaluate:\n>     - The implications of combining this data with the user-agent.\n>     - How this approach might address concerns about telemetry and user privacy.\n>\n> Implement Default Behavior for 'os-version'\n> ----------------------------------------------------------\n> 1. Modify Default Configuration: Adjust the implementation so that by\n> default, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\n> communications.\n> 2. Impact Assessment: Evaluate how this change impacts existing users\n> and any potential performance implications.\n>\n> Introduce a Configuration Variable\n> ---------------------------------------------\n> 1. Define Configuration Options\n>     - Disable Option: Allow users to disable the 'os-version'\n> capability entirely via configuration.\n>     - Verbose Option: Enable a verbose mode that sends detailed OS\n> information (e.g., the output of the uname -srvm command).\n>\n> 2. Documentation: Improve the documentation outlining how to enable,\n> disable, and configure the 'os-version' capability. Include examples\n> for:\n>     - Basic usage (default OS name).\n>     - Detailed usage (full OS version information).\n> 3. Implementation: Code the configuration settings and ensure they are\n> recognized by the Git system.\n>\n> Fix Cross-Platform Tests\n> ---------------------------------\n>\n> 1. Identify Issues and added tests for changes/addition: Investigate\n> existing test failures, particularly those occurring on Windows and .\n>      - Review the test logs and identify the root causes of failures.\n>      - Analyze differences in OS behaviors and how they affect the tests.\n>      - Cross-platform tests to validate the functionality on Linux,\n> Windows, and macOS environments.\n> 2. Implement Fixes:\n>       - Modify tests to ensure they run correctly on Windows,\n> addressing any compatibility issues with the test framework or Git\n> commands.\n>       - Ensure all tests reflect the changes made to the OS reporting\n> capabilities.\n>\n> Testing and Validation\n> ------------------------------\n> Ensure comprehensive test coverage—including default behavior,\n> configuration options, and edge cases—integrate tests into the Git CI\n> pipeline for automatic execution, and share results with the community\n> for feedback on robustness and additional scenarios.\n>\n> Documentation Updates\n> ---------------------------------\n>\n> 1. User Documentation: Update the Git documentation to include:\n>     - Instructions on how to configure the feature, with practical examples.\n>     - Best practices regarding data privacy when using the capability.\n> 2 Developer Documentation: Include comments in the code for\n> maintainability and understanding of how the 'os-version' capability\n> works internally.\n>\n>  Prepare for Merging\n> ----------------------------\n> 1. Final Review: Conduct a thorough review of all code, tests, and\n> documentation. Ensure everything aligns with Git’s contribution\n> standards.\n> 2. Engagement with Community: Present the finalized patch to the Git\n> mailing list, addressing any additional concerns raised during the\n> discussions.\n> 3. Merge Process: Coordinate with the maintainers for merging the\n> patch into the main branch, ensuring all feedback has been\n> incorporated.\n>\n>\n> —------------------------- Timeline —-------------------------------------\n>\n> Community Feedback and Finalization\n> =============================\n> Dates: November 26 - December 8\n> Engage with the Git community to gather input, especially on privacy\n> concerns and minimal data sharing. Determine default behavior (sharing\n> only OS name) and finalize whether to use \"user-agent\" or another\n> identifier in the protocol(os-version).\n>\n> Minimal Default Implementation\n> ========================\n> Dates: December 9 - December 20\n> Implement the core feature to share only the OS name by default,\n> keeping data minimal as per feedback.\n>\n> Configurable Options for OS Version\n> ============================\n>\n> Dates: December 21 - December 30\n> Develop settings to allow users to disable OS data sharing or choose\n> verbose mode (e.g., uname -srvm output).\n>\n> Cross-Platform Testing (Focus on Windows)\n> ==================================\n>\n> Dates: December 31 - January 13\n> Conduct robust testing across platforms, addressing prior Windows\n> compatibility issues.\n>\n> Beta Testing and Community Feedback\n> ==============================\n> Dates: January 14 - January 27\n> Release for beta testing, integrate feedback, and refine functionality\n> based on real-world use.\n>\n> Documentation\n> ============\n> Dates: January 28 - February 10\n> Document feature usage, configuration options, and setup instructions\n> for smooth adoption.\n>\n> Final Review and Merge\n> ===================\n> Dates: February 11 - March 6\n> The final review phase will include presenting the completed work to\n> the Git community for a thorough final assessment. Any remaining\n> concerns or suggestions will be addressed before the patch is prepared\n> for merge. This stage will allow for further feedback, particularly\n> from stakeholders and maintainers who raised the initial questions,\n> ensuring the solution is acceptable to the broad Git community. Once\n> consensus is achieved, the patch will be merged into the Git mainline\n> codebase, concluding the project.\n>\n>\n> Availability\n> ========\n> I will be available to work for the required minimum of 30 hours\n> during the internship period and will be happy to extend if required.\n>\n> Blogging\n> =======\n> I also plan to keep writing blogs after two weeks, to track my\n> progress,  give updates about what I am currently working on and also\n> as a documentation for future contributors.\n>\n> Post Outreachy Internship\n> ====================\n> One of my dreams is to be an active member of an open-source community\n> which I can proudly support and contribute to. Continuing my\n> contributions after the internship is a big part of making that dream\n> a reality. I’m committed to contributing to Git long-term, helping to\n> improve the project and supporting new contributors along the way.\n>\n> Appreciation\n> ==========\n> I really appreciate the support and guidance I got from the git\n> community. I also appreciate all the effort from the outreachy mentor.\n> Thanks for your time.\n>\n> Thank you.\n> Usman Akinyemi.\n"},{"id":"506200","messageId":"Zx8q7jnDIS3_omBm@pks.im","threadId":"62413","inReplyTo":"CAPSxiM-YAAMwOvH8KYO+qKahCBHgw-NDb-eHJKNCZyk8xtpeGQ@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-28T06:10:54Z","receivedAt":"2024-10-28T06:11:05Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Oct 28, 2024 at 01:56:36AM +0000, Usman Akinyemi wrote:\n> Hello,\n> \n> As I planned to submit a proposal for two projects, below is my\n> proposal for \"Conversion of Git Unit Tests to Clar Testing Framework\".\n> I would just go straight into the project proposals as the other\n> necessary information is in the previous email. I would prefer to work\n> on the \"Finish adding a 'os-version' capability to Git protocol v2\"\n> project in case.\n\nThanks for your applications! I'll only reply to this email as I'm not\nmentoring the other project.\n\n[snip]\n> ---- December 23 - February 10: Incremental Conversions & Feedback\n> Integration -----\n> \n> - File Renaming: Rename test files from t-<name>.c to <name>.c\n> following the structure outlined by prior contributions.\n> - Clar Suite Integration: Add the module name to CLAR_TEST_SUITE in\n> the Makefile to include the file in the Clar testing suite.\n> - Conversion of Test Assertions: Replace the test assertions with\n> Clar’s built-in functions (cl_assert, cl_assert_equal_s,\n> cl_assert_equal_i, etc.), enhancing readability and functionality.\n> -  Patch Submission: Submit each converted test as an incremental\n> patch to Git's mailing list following the Git contribution guidelines.\n> This phased approach enables targeted feedback from the community.\n\nOne thing missing here is the work with upstream in case we want to\nimplement any functionality that doesn't yet exist in clar. You mention\nit in \"Additional Goals and Extensions\" though, so that might be good\nenough.\n\nOther than that this looks good to me, thanks! Please don't forget to\nupload your applications to Outreachy if you haven't done so already.\n\nPatrick\n"},{"id":"506201","messageId":"CAPSxiM92YO8askO7h=1jOy5PfOdrAfaKiSFv7aRL0iCT4BcTzg@mail.gmail.com","threadId":"62413","inReplyTo":"Zx8q7jnDIS3_omBm@pks.im","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-10-28T06:20:21Z","receivedAt":"2024-10-28T06:20:33Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Mon, Oct 28, 2024 at 6:11 AM Patrick Steinhardt <ps@pks.im> wrote:\n>\n> On Mon, Oct 28, 2024 at 01:56:36AM +0000, Usman Akinyemi wrote:\n> > Hello,\n> >\n> > As I planned to submit a proposal for two projects, below is my\n> > proposal for \"Conversion of Git Unit Tests to Clar Testing Framework\".\n> > I would just go straight into the project proposals as the other\n> > necessary information is in the previous email. I would prefer to work\n> > on the \"Finish adding a 'os-version' capability to Git protocol v2\"\n> > project in case.\n>\n> Thanks for your applications! I'll only reply to this email as I'm not\n> mentoring the other project.\n>\n> [snip]\n> > ---- December 23 - February 10: Incremental Conversions & Feedback\n> > Integration -----\n> >\n> > - File Renaming: Rename test files from t-<name>.c to <name>.c\n> > following the structure outlined by prior contributions.\n> > - Clar Suite Integration: Add the module name to CLAR_TEST_SUITE in\n> > the Makefile to include the file in the Clar testing suite.\n> > - Conversion of Test Assertions: Replace the test assertions with\n> > Clar’s built-in functions (cl_assert, cl_assert_equal_s,\n> > cl_assert_equal_i, etc.), enhancing readability and functionality.\n> > -  Patch Submission: Submit each converted test as an incremental\n> > patch to Git's mailing list following the Git contribution guidelines.\n> > This phased approach enables targeted feedback from the community.\n>\n> One thing missing here is the work with upstream in case we want to\n> implement any functionality that doesn't yet exist in clar. You mention\n> it in \"Additional Goals and Extensions\" though, so that might be good\n> enough.\n>\n> Other than that this looks good to me, thanks! Please don't forget to\n> upload your applications to Outreachy if you haven't done so already.\n>\nHi, Patrick\nThanks for your review.\nWill it be better to include *work with upstream* as part of the whole\ntimeline instead of adding it as an Additional Goals and Extensions?\n\nThanks.\n> Patrick\n"},{"id":"506204","messageId":"Zx89jzejV3lMxWr8@pks.im","threadId":"62413","inReplyTo":"CAPSxiM92YO8askO7h=1jOy5PfOdrAfaKiSFv7aRL0iCT4BcTzg@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-28T07:30:23Z","receivedAt":"2024-10-28T07:30:33Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Oct 28, 2024 at 06:20:21AM +0000, Usman Akinyemi wrote:\n> On Mon, Oct 28, 2024 at 6:11 AM Patrick Steinhardt <ps@pks.im> wrote:\n> > > ---- December 23 - February 10: Incremental Conversions & Feedback\n> > > Integration -----\n> > >\n> > > - File Renaming: Rename test files from t-<name>.c to <name>.c\n> > > following the structure outlined by prior contributions.\n> > > - Clar Suite Integration: Add the module name to CLAR_TEST_SUITE in\n> > > the Makefile to include the file in the Clar testing suite.\n> > > - Conversion of Test Assertions: Replace the test assertions with\n> > > Clar’s built-in functions (cl_assert, cl_assert_equal_s,\n> > > cl_assert_equal_i, etc.), enhancing readability and functionality.\n> > > -  Patch Submission: Submit each converted test as an incremental\n> > > patch to Git's mailing list following the Git contribution guidelines.\n> > > This phased approach enables targeted feedback from the community.\n> >\n> > One thing missing here is the work with upstream in case we want to\n> > implement any functionality that doesn't yet exist in clar. You mention\n> > it in \"Additional Goals and Extensions\" though, so that might be good\n> > enough.\n> >\n> > Other than that this looks good to me, thanks! Please don't forget to\n> > upload your applications to Outreachy if you haven't done so already.\n> >\n> Hi, Patrick\n> Thanks for your review.\n> Will it be better to include *work with upstream* as part of the whole\n> timeline instead of adding it as an Additional Goals and Extensions?\n\nI don't mind it too much, and as mentioned elsewhere I think that it's\nperfectly fine if the timeline is rough. It's more about demonstrating\nthat you're aware of the steps, which you seem to be.\n\nPatrick\n"},{"id":"506206","messageId":"CAP8UFD2pLppDC9b-JV-uQa8x8xmpeTSJ4szHOEPz1OfqzrOMPw@mail.gmail.com","threadId":"62413","inReplyTo":"CAPSxiM-4okXfiWZtSNArMjfXzja9wBrMaEayhqt1hvJpu-PHkQ@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-10-28T08:26:16Z","receivedAt":"2024-10-28T08:26:30Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Usman,\n\nOn Sun, Oct 27, 2024 at 3:54 PM Usman Akinyemi\n<usmanakinyemi202@gmail.com> wrote:\n>\n> Hello Git Community,\n>\n> I hope this mail finds you well.\n>\n> This is my proposal for the project \"Finish adding a 'os-version'\n> capability to Git protocol v2\" for Outreachy internship program 2024.\n>\n> I appreciate any feedback on this proposal.\n\nThanks for this proposal! You will find my feedback below.\n\n> ---------<8----------<8----------<8----------<8----------<8----------<8\n>\n> Personal Information\n> ================\n>\n> Full Name: Usman Akinyemi\n> Email: usmanakinyemi202@gmail.com\n> Personal Blog: https://uniqueusman.hashnode.dev/\n> Personal Website: https://uniqueusman.tech\n> GitHub: https://github.com/Unique-Usman\n> Degree: Bachelor of Technology (B.Tech) in Computer Science and\n> Artificial Intelligence\n>\n>\n> About Me\n> ========\n>\n> I am Usman Akinyemi, I often like to refer to myself as a nomadic\n> computer programmer as I love the ability to work on interesting\n> projects without being restricted to a physical location. I love the\n> Linux Operating System and most people already alias my name to Linux\n> as I also preach it to everyone everyday. I learnt programming in\n> multiple places, in college,  ALX Software Engineering program and\n> also personal studying. I have decent experience in contributing to\n> OpenSource projects. I have contributed to systemd, Cpython\n> documentation, Canonical website,  pep8speaks and Open Science\n> Initiative for Perfusion Imaging (OSIPI). Being someone who is a\n> product of the community, I value community development so much. I\n> have always tried my best to contribute to the community in my own\n> way. One case is when I organized a month-long program(structured\n> webinar) aimed at exposing young Nigerians to opportunities in tech.\n> The program focuses on topics such as OpenSource contributions,\n> securing internships, career development, freelancing, datascience,\n> and introduction to Github and Linux([ Youtube Recording\n> ]https://www.youtube.com/watch?v=OrAThr-84t8&list=PLBW_HlYT-kP1tUqbzavMAq-ZZQRhMkZH2&ab_channel=UsmanAkinyemi\n> ). I have also volunteered for different communities one of which is\n> DesignIT where we train Nigerian youth on technology.\n>\n>\n> Past Experience with Git\n> ===================\n> I have been a Git user for about three years now. I mainly use git for\n> personal projects, Group projects and OpenSource contributions. I have\n> also had the opportunity to introduce and teach people to Git. I am\n> really excited to be here in the Git community.\n> During the contribution stage, I have got more familiar with the\n> community and how to send patches to Git with the help of the Git\n> community. I have also learnt a couple of things, one of which is Git\n> contributor best practices.\n>\n>\n> Contributions to the Git Community\n> ===========================\n>\n> I joined the Git community after I got selected for Outreachy\n> Contribution Phase and I have been able to send some patches to the\n> Git codebase with the help of the Git community while also learning.\n> Below is the list of my contributions:\n>\n> MICROPROJECT\n> ------------------------\n> - Link: https://public-inbox.org/git/pull.1805.git.git.1728192814.gitgitgadget@gmail.com/T/#u\n> - Merge Commit: 6487b2b\n\nThe commit is now 26b7b76329e03252c2738d7af90b5c18db3e98e1. As 'next'\nand 'seen' are rebuilt on top of 'master', the commit id changes so it\nmight be better to just give the branch name, here \"ua/t3404-cleanup\"\nfor branches that are not yet merged into 'master'.\n\n> - Status: merged into next/jch\n\n> + [PATCH v7 1/2] t3404: avoid losing exit status with focus on `git\n> show` and `git cat-file`\n> - Description: In the Git t3404 test script, I improved error\n> detection by restructuring command chains to ensure accurate exit\n> status handling, preventing missed errors from piped commands.\n> The exit code of the preceding command in a pipe is disregarded. So if\n> that preceding command is a Git command that fails, the test would not\n> fail. Instead, by saving the output of that Git command to a file, and\n> removing the pipe, we make sure the test will fail if that Git\n> command fails. This particular patch focuses on all `git show` and\n> some instances of `git cat-file`.\n>\n> + [PATCH v7 2/2] t3404: replace test with test_line_count()\n> - Description: Refactor t3404 to replace instances of `test` with\n> `test_line_count()` for checking line counts. This improves\n> readability and aligns with Git's current test practices.\n>\n> - Remarks: Through this process, I deepened my understanding of shell\n> scripting and command chaining, focusing on how exit statuses affect\n> testing accuracy. My mentors suggested keeping commands readable and\n> consistent with Git's scripting standards, emphasizing simplicity and\n> future maintainability. The result is a more robust, reliable test\n> script that better aligns with Git’s best practices, improving overall\n> test suite integrity. Also, through this patch, I was able to\n> understand the workflow involved in submitting a patch to git which is\n\nNit: s/git/Git/\n\n> quite different from many other projects which I have worked on. This\n> is really an interesting learning experience.\n> I also learnt about the importance of following Git’s best practices\n> and also How  to submit patches with multiple commits.\n\nNit: s/How  to/how to/\n\n> LeftOverbits\n> -----------------\n> - Link: https://public-inbox.org/git/pull.1810.v3.git.git.1729574624.gitgitgadget@gmail.com/T/#t\n> - Merge Commit: cfd82c9\n\nHere also the merge commit is now\necd980f7eb8f24fa6ca85e35288d02909b1ba64a, so better just give the\n'ua/atoi' branch name.\n\n> - Status: merged into next/jch\n>\n> After completing the microproject, I wanted to gain a deeper\n> understanding of Git’s codebase and workflow. I began looking through\n> leftoverbits to work on and found a suitable one. Through this, I\n> learned how to add tests for my code additions, which helped me\n> understand the process of integrating and validating changes in the\n> codebase.\n>\n> - General Description: In this series of patches, I replaced `atoi()`\n> with `strtoul_ui()` and `strtol_i()` across the daemon, merge, and\n> IMAP components to address the issue of inadequate error handling and\n> input validation. The use of `atoi()` could lead to undefined behavior\n> when parsing invalid inputs, such as letters, which might result in\n> incorrect program behavior. Now, invalid inputs trigger clear error\n> messages, ensuring safer parsing and preventing malformed responses. I\n> updated tests for the daemon and merged components to verify these\n> improvements, while IMAP changes didn't include tests since none\n> existed for `git-imap-send`. Overall, this update significantly\n> strengthens input validation and code reliability.\n>\n> + [PATCH v6 1/3] daemon: replace atoi() with strtoul_ui() and strtol_i()\n> Replace atoi() with strtoul_ui() for --timeout and --init-timeout\n> (non-negative integers) and with strtol_i() for --max-connections\n> (signed integers). This improves error handling and input validation\n> by detecting invalid values and providing clear error messages.\n>\n> + [PATCH v6 2/3] merge: replace atoi() with strtol_i() for marker size\n> validation\n> Replace atoi() with strtol_i() for parsing conflict-marker-size to\n> improve error handling. Invalid values, such as those containing\n> letters now trigger a clear error message.\n>\n> + [PATCH v6 3/3] imap: replace atoi() with strtol_i() for UIDVALIDITY\n> and UIDNEXT\n> Replace unsafe uses of atoi() with strtol_i() to improve error handling\n> when parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands.\n> Invalid values, such as those with letters, now trigger error messages\n> and prevent malformed status responses.\n>\n> - Remarks: In this patch series, I learnt a lot of things. The\n> importance of splitting large changes into Smaller changes for easy\n> review. I also learnt about how to submit multiple patches which are\n> not related by creating a new branch from origin/master. Also, I\n> learnt how to write better commit messages. And lastly, the importance\n> of asking for help and integrating suggestions from the community.\n>\n> I also had the opportunity to review a patch and also answer doubt\n> from other outreachy applicant mate\n\nNit: s/outreachy/Outreachy/\n\n> https://public-inbox.org/git/CAEqABkKvbpo-8-gDpFtfNcpmiC8A5mJMkcDXfhcdNrpwMvBsDA@mail.gmail.com/T/#u\n> https://public-inbox.org/git/CAPSxiM8SjJwb6x2bhCd4xsYLiNk+KhWYna7-rZhdNGpYNV1tLg@mail.gmail.com/\n>\n>\n> Past experience with other communities\n> ===============================\n>\n> Systemd\n> ------------\n>\n> - I Developed a new unit test framework with assertion macros which\n> enhanced debugging by providing detailed error reports with file\n> names, line numbers, and expression values upon failure, improving\n> issue identification and resolution\n> - I Updated approximately 22 existing unit test files by modifying 403\n> lines of code to incorporate the new assertion macros, resulting in\n> improved logging details and enhanced overall test coverage and\n> debugging efficiency.\n> - I Implemented the --json option for the bootctl status command and\n> updated the integration tests, enabling machine-readable JSON output\n> for comprehensive bootloader status information\n>\n> PR Link:\n> https://github.com/systemd/systemd/pull/31873\n> https://github.com/systemd/systemd/pull/31853\n> https://github.com/systemd/systemd/pull/31819\n> https://github.com/systemd/systemd/pull/31700\n> https://github.com/systemd/systemd/pull/31678\n> https://github.com/systemd/systemd/pull/31669\n> https://github.com/systemd/systemd/pull/31666\n> https://github.com/systemd/systemd/pull/32035\n>\n> Python Official Documentation\n> -----------------------------------------\n> - I have contributed to improving Python's official documentation,\n> enhancing my Python knowledge, technical writing, and collaboration\n> skills in open-source.\n>\n> PR Link:\n> https://github.com/python/cpython/pull/109696\n> https://github.com/python/cpython/pull/111574\n> https://github.com/python/docs-community/pull/96\n> https://github.com/python/cpython/pull/113209\n> https://github.com/python/docs-community/pull/97\n>\n> OSIPI (Open Science Initiative for Perfusion Imaging(OSIPI) organization)\n\nNit: s/(OSIPI)//\n\n> ---------------------------------------------------------------------------------------------------\n> - Added a command-line interface to the existing 4D IVIM phantoms\n> generator, with detailed documentation for usage.\n> - Created a Python script for efficient reading and writing of NIfTI\n> images, improving data processing workflows.\n> - Dockerized the TF2.4_IVIM-MRI_CodeCollection project and implemented\n> a GitHub Action for automated Docker image building and testing,\n> ensuring consistent deployment and a streamlined CI/CD pipeline.\n>\n> PR Link:\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/92a80d61cfca322da49d126dcd598996fca92668\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/163a187c5eaad33b55a0af0487bd9e19ca520828\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/56ee7173c91c7a1dd64412d3884a3167c7514665\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/e6a47211410ed57705e2ec32adb397ac6663d061\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/60\n> https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/74\n>\n> Canonical Docs Website\n> ---------------------------------\n> I developed a solution to integrate GitHub contributor information\n> into Sphinx documentation templates using the GitHub API, enhancing\n> documentation with contributor insights.\n>\n> PR Link:\n> https://github.com/canonical/sphinx-docs-starter-pack/pull/203#issuecomment-2018521984\n>\n> LLVM\n> --------\n> I fixed a bug in Clang's Extract API for Objective-C JSON generation\n> and optimized the test suite within the LLVM Compiler Infrastructure.\n> https://github.com/Unique-Usman/llvm-project/commit/32b53cf9d0c8c0e01ce5b0e7d5c717202a98cdf5\n>\n>\n> Experience As a user of OpenSource Software\n\nNit: s/As/as/\n\n> ====================================\n>\n> As an avid user of open-source software, my experience has been\n> primarily with Linux distributions, particularly Arch, which serves as\n> my primary operating system. My past usage of Ubuntu has also\n> contributed to my understanding of different Linux environments.\n> In addition, I have extensively utilized various free software such as\n> MySQL for database management, LibreOffice for office productivity,\n> GCC and G++ for C and C++ programming, Python for scripting and\n> application development, React for web development, Clang for C/C++\n> compilation, Git for version control and many others. These\n> experiences have not only enriched my software knowledge but have also\n> deepened my understanding of the principles and benefits of\n> open-source development.\n>\n>\n> —--------------------------------- Project Overview\n> —--—--------------------------------\n> In June 2024, a patch series was submitted to the Git mailing list\n> aimed at adding a new 'os-version' capability to the Git protocol v2.\n> This capability is designed to allow Git clients and servers to\n> exchange information about the Operating System (OS) they are using,\n> which can aid in diagnosing issues and collecting statistical data.\n> Following the patch submission, discussions arose regarding the\n> necessary improvements and issues, particularly with Windows\n> compatibility.\n> The objective of this internship is to address these outstanding\n> issues, implement the required improvements, and ensure the successful\n> integration of the 'os-version' capability into the Git protocol.\n>\n> —------- Internship objectives and plans  —-------\n> The goal of this internship is to finalize the implementation of the\n> 'os-version' capability in Git protocol v2, as proposed in the patch\n> series sent to the Git mailing list in June 2024. This enhancement\n> will allow Git clients and servers to advertise their operating\n> systems (OS), aiding in diagnostics and data collection.\n>\n> Detailed Tasks and Steps\n> ====================\n>\n> Review the Current Patch Series\n> --------------------------------------------\n> 1. Examine the Patch: Thoroughly analyze the existing patch series\n> submitted to the Git mailing list. Understand its design and\n> functionality, focusing on:\n>    -  How the OS information is gathered and transmitted.\n>    -  Current configurations and their implications on data transmission.\n> 2. Feedback Analysis: Collect feedback from the Git mailing list\n> discussion regarding the patch. Identify key concerns, especially\n> related to:\n>     - Privacy issues.\n>     - Default behavior expectations.\n>     - Cross-platform compatibility.\n> 3. Consider User-Agent Integration: Investigate the suggestion to\n> integrate the 'os-version' data into the existing user-agent string\n> rather than creating a new capability. Evaluate:\n>     - The implications of combining this data with the user-agent.\n>     - How this approach might address concerns about telemetry and user privacy.\n>\n> Implement Default Behavior for 'os-version'\n> ----------------------------------------------------------\n> 1. Modify Default Configuration: Adjust the implementation so that by\n> default, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\n> communications.\n> 2. Impact Assessment: Evaluate how this change impacts existing users\n> and any potential performance implications.\n>\n> Introduce a Configuration Variable\n> ---------------------------------------------\n> 1. Define Configuration Options\n>     - Disable Option: Allow users to disable the 'os-version'\n> capability entirely via configuration.\n>     - Verbose Option: Enable a verbose mode that sends detailed OS\n> information (e.g., the output of the uname -srvm command).\n\nShouldn't there be a config option corresponding to the default\nbehavior (which would be to show only the OS Name like \"Linux\",\n\"Windows\", etc.) ?\n\nAlso what if users want something more customized, like perhaps \"OS:\nLinux, Arch: x86_64\"?\n\n> 2. Documentation: Improve the documentation outlining how to enable,\n> disable, and configure the 'os-version' capability. Include examples\n> for:\n>     - Basic usage (default OS name).\n>     - Detailed usage (full OS version information).\n> 3. Implementation: Code the configuration settings and ensure they are\n> recognized by the Git system.\n>\n> Fix Cross-Platform Tests\n> ---------------------------------\n>\n> 1. Identify Issues and added tests for changes/addition: Investigate\n> existing test failures, particularly those occurring on Windows and .\n>      - Review the test logs and identify the root causes of failures.\n>      - Analyze differences in OS behaviors and how they affect the tests.\n>      - Cross-platform tests to validate the functionality on Linux,\n> Windows, and macOS environments.\n> 2. Implement Fixes:\n>       - Modify tests to ensure they run correctly on Windows,\n> addressing any compatibility issues with the test framework or Git\n> commands.\n>       - Ensure all tests reflect the changes made to the OS reporting\n> capabilities.\n>\n> Testing and Validation\n> ------------------------------\n> Ensure comprehensive test coverage—including default behavior,\n> configuration options, and edge cases—integrate tests into the Git CI\n> pipeline for automatic execution, and share results with the community\n> for feedback on robustness and additional scenarios.\n>\n> Documentation Updates\n> ---------------------------------\n>\n> 1. User Documentation: Update the Git documentation to include:\n>     - Instructions on how to configure the feature, with practical examples.\n>     - Best practices regarding data privacy when using the capability.\n> 2 Developer Documentation: Include comments in the code for\n> maintainability and understanding of how the 'os-version' capability\n> works internally.\n>\n>  Prepare for Merging\n> ----------------------------\n> 1. Final Review: Conduct a thorough review of all code, tests, and\n> documentation. Ensure everything aligns with Git’s contribution\n> standards.\n> 2. Engagement with Community: Present the finalized patch to the Git\n> mailing list, addressing any additional concerns raised during the\n> discussions.\n> 3. Merge Process: Coordinate with the maintainers for merging the\n> patch into the main branch, ensuring all feedback has been\n> incorporated.\n>\n>\n> —------------------------- Timeline —-------------------------------------\n>\n> Community Feedback and Finalization\n> =============================\n> Dates: November 26 - December 8\n> Engage with the Git community to gather input, especially on privacy\n> concerns and minimal data sharing. Determine default behavior (sharing\n> only OS name) and finalize whether to use \"user-agent\" or another\n> identifier in the protocol(os-version).\n>\n> Minimal Default Implementation\n> ========================\n> Dates: December 9 - December 20\n> Implement the core feature to share only the OS name by default,\n> keeping data minimal as per feedback.\n>\n> Configurable Options for OS Version\n> ============================\n>\n> Dates: December 21 - December 30\n> Develop settings to allow users to disable OS data sharing or choose\n> verbose mode (e.g., uname -srvm output).\n>\n> Cross-Platform Testing (Focus on Windows)\n> ==================================\n>\n> Dates: December 31 - January 13\n> Conduct robust testing across platforms, addressing prior Windows\n> compatibility issues.\n>\n> Beta Testing and Community Feedback\n> ==============================\n> Dates: January 14 - January 27\n> Release for beta testing, integrate feedback, and refine functionality\n> based on real-world use.\n>\n> Documentation\n> ============\n> Dates: January 28 - February 10\n> Document feature usage, configuration options, and setup instructions\n> for smooth adoption.\n>\n> Final Review and Merge\n> ===================\n> Dates: February 11 - March 6\n> The final review phase will include presenting the completed work to\n> the Git community for a thorough final assessment. Any remaining\n> concerns or suggestions will be addressed before the patch is prepared\n> for merge. This stage will allow for further feedback, particularly\n> from stakeholders and maintainers who raised the initial questions,\n> ensuring the solution is acceptable to the broad Git community. Once\n> consensus is achieved, the patch will be merged into the Git mainline\n> codebase, concluding the project.\n>\n>\n> Availability\n> ========\n> I will be available to work for the required minimum of 30 hours\n> during the internship period and will be happy to extend if required.\n\nDo you mean 30 hours total or 30 hours per week?\n\n> Blogging\n> =======\n> I also plan to keep writing blogs after two weeks, to track my\n> progress,  give updates about what I am currently working on and also\n> as a documentation for future contributors.\n>\n> Post Outreachy Internship\n> ====================\n> One of my dreams is to be an active member of an open-source community\n> which I can proudly support and contribute to. Continuing my\n> contributions after the internship is a big part of making that dream\n> a reality. I’m committed to contributing to Git long-term, helping to\n> improve the project and supporting new contributors along the way.\n>\n> Appreciation\n> ==========\n> I really appreciate the support and guidance I got from the git\n\nNit: s/git/Git/\n\n> community. I also appreciate all the effort from the outreachy mentor.\n> Thanks for your time.\n\nThanks,\nChristian.\n"},{"id":"506208","messageId":"CAPSxiM8NgFUK8R0TrE1nPctOYSD6M8cCe7=xJuniXWO2g-C6Nw@mail.gmail.com","threadId":"62413","inReplyTo":"CAP8UFD2pLppDC9b-JV-uQa8x8xmpeTSJ4szHOEPz1OfqzrOMPw@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-10-28T09:09:25Z","receivedAt":"2024-10-28T09:09:37Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Mon, Oct 28, 2024 at 8:26 AM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi Usman,\n>\n> On Sun, Oct 27, 2024 at 3:54 PM Usman Akinyemi\n> <usmanakinyemi202@gmail.com> wrote:\n> >\n> > Hello Git Community,\n> >\n> > I hope this mail finds you well.\n> >\n> > This is my proposal for the project \"Finish adding a 'os-version'\n> > capability to Git protocol v2\" for Outreachy internship program 2024.\n> >\n> > I appreciate any feedback on this proposal.\n>\n> Thanks for this proposal! You will find my feedback below.\n>\n> > ---------<8----------<8----------<8----------<8----------<8----------<8\n> >\n> > Personal Information\n> > ================\n> >\n> > Full Name: Usman Akinyemi\n> > Email: usmanakinyemi202@gmail.com\n> > Personal Blog: https://uniqueusman.hashnode.dev/\n> > Personal Website: https://uniqueusman.tech\n> > GitHub: https://github.com/Unique-Usman\n> > Degree: Bachelor of Technology (B.Tech) in Computer Science and\n> > Artificial Intelligence\n> >\n> >\n> > About Me\n> > ========\n> >\n> > I am Usman Akinyemi, I often like to refer to myself as a nomadic\n> > computer programmer as I love the ability to work on interesting\n> > projects without being restricted to a physical location. I love the\n> > Linux Operating System and most people already alias my name to Linux\n> > as I also preach it to everyone everyday. I learnt programming in\n> > multiple places, in college,  ALX Software Engineering program and\n> > also personal studying. I have decent experience in contributing to\n> > OpenSource projects. I have contributed to systemd, Cpython\n> > documentation, Canonical website,  pep8speaks and Open Science\n> > Initiative for Perfusion Imaging (OSIPI). Being someone who is a\n> > product of the community, I value community development so much. I\n> > have always tried my best to contribute to the community in my own\n> > way. One case is when I organized a month-long program(structured\n> > webinar) aimed at exposing young Nigerians to opportunities in tech.\n> > The program focuses on topics such as OpenSource contributions,\n> > securing internships, career development, freelancing, datascience,\n> > and introduction to Github and Linux([ Youtube Recording\n> > ]https://www.youtube.com/watch?v=OrAThr-84t8&list=PLBW_HlYT-kP1tUqbzavMAq-ZZQRhMkZH2&ab_channel=UsmanAkinyemi\n> > ). I have also volunteered for different communities one of which is\n> > DesignIT where we train Nigerian youth on technology.\n> >\n> >\n> > Past Experience with Git\n> > ===================\n> > I have been a Git user for about three years now. I mainly use git for\n> > personal projects, Group projects and OpenSource contributions. I have\n> > also had the opportunity to introduce and teach people to Git. I am\n> > really excited to be here in the Git community.\n> > During the contribution stage, I have got more familiar with the\n> > community and how to send patches to Git with the help of the Git\n> > community. I have also learnt a couple of things, one of which is Git\n> > contributor best practices.\n> >\n> >\n> > Contributions to the Git Community\n> > ===========================\n> >\n> > I joined the Git community after I got selected for Outreachy\n> > Contribution Phase and I have been able to send some patches to the\n> > Git codebase with the help of the Git community while also learning.\n> > Below is the list of my contributions:\n> >\n> > MICROPROJECT\n> > ------------------------\n> > - Link: https://public-inbox.org/git/pull.1805.git.git.1728192814.gitgitgadget@gmail.com/T/#u\n> > - Merge Commit: 6487b2b\n>\n> The commit is now 26b7b76329e03252c2738d7af90b5c18db3e98e1. As 'next'\n> and 'seen' are rebuilt on top of 'master', the commit id changes so it\n> might be better to just give the branch name, here \"ua/t3404-cleanup\"\n> for branches that are not yet merged into 'master'.\n>\n> > - Status: merged into next/jch\n>\n> > + [PATCH v7 1/2] t3404: avoid losing exit status with focus on `git\n> > show` and `git cat-file`\n> > - Description: In the Git t3404 test script, I improved error\n> > detection by restructuring command chains to ensure accurate exit\n> > status handling, preventing missed errors from piped commands.\n> > The exit code of the preceding command in a pipe is disregarded. So if\n> > that preceding command is a Git command that fails, the test would not\n> > fail. Instead, by saving the output of that Git command to a file, and\n> > removing the pipe, we make sure the test will fail if that Git\n> > command fails. This particular patch focuses on all `git show` and\n> > some instances of `git cat-file`.\n> >\n> > + [PATCH v7 2/2] t3404: replace test with test_line_count()\n> > - Description: Refactor t3404 to replace instances of `test` with\n> > `test_line_count()` for checking line counts. This improves\n> > readability and aligns with Git's current test practices.\n> >\n> > - Remarks: Through this process, I deepened my understanding of shell\n> > scripting and command chaining, focusing on how exit statuses affect\n> > testing accuracy. My mentors suggested keeping commands readable and\n> > consistent with Git's scripting standards, emphasizing simplicity and\n> > future maintainability. The result is a more robust, reliable test\n> > script that better aligns with Git’s best practices, improving overall\n> > test suite integrity. Also, through this patch, I was able to\n> > understand the workflow involved in submitting a patch to git which is\n>\n> Nit: s/git/Git/\n>\n> > quite different from many other projects which I have worked on. This\n> > is really an interesting learning experience.\n> > I also learnt about the importance of following Git’s best practices\n> > and also How  to submit patches with multiple commits.\n>\n> Nit: s/How  to/how to/\n>\n> > LeftOverbits\n> > -----------------\n> > - Link: https://public-inbox.org/git/pull.1810.v3.git.git.1729574624.gitgitgadget@gmail.com/T/#t\n> > - Merge Commit: cfd82c9\n>\n> Here also the merge commit is now\n> ecd980f7eb8f24fa6ca85e35288d02909b1ba64a, so better just give the\n> 'ua/atoi' branch name.\n>\n> > - Status: merged into next/jch\n> >\n> > After completing the microproject, I wanted to gain a deeper\n> > understanding of Git’s codebase and workflow. I began looking through\n> > leftoverbits to work on and found a suitable one. Through this, I\n> > learned how to add tests for my code additions, which helped me\n> > understand the process of integrating and validating changes in the\n> > codebase.\n> >\n> > - General Description: In this series of patches, I replaced `atoi()`\n> > with `strtoul_ui()` and `strtol_i()` across the daemon, merge, and\n> > IMAP components to address the issue of inadequate error handling and\n> > input validation. The use of `atoi()` could lead to undefined behavior\n> > when parsing invalid inputs, such as letters, which might result in\n> > incorrect program behavior. Now, invalid inputs trigger clear error\n> > messages, ensuring safer parsing and preventing malformed responses. I\n> > updated tests for the daemon and merged components to verify these\n> > improvements, while IMAP changes didn't include tests since none\n> > existed for `git-imap-send`. Overall, this update significantly\n> > strengthens input validation and code reliability.\n> >\n> > + [PATCH v6 1/3] daemon: replace atoi() with strtoul_ui() and strtol_i()\n> > Replace atoi() with strtoul_ui() for --timeout and --init-timeout\n> > (non-negative integers) and with strtol_i() for --max-connections\n> > (signed integers). This improves error handling and input validation\n> > by detecting invalid values and providing clear error messages.\n> >\n> > + [PATCH v6 2/3] merge: replace atoi() with strtol_i() for marker size\n> > validation\n> > Replace atoi() with strtol_i() for parsing conflict-marker-size to\n> > improve error handling. Invalid values, such as those containing\n> > letters now trigger a clear error message.\n> >\n> > + [PATCH v6 3/3] imap: replace atoi() with strtol_i() for UIDVALIDITY\n> > and UIDNEXT\n> > Replace unsafe uses of atoi() with strtol_i() to improve error handling\n> > when parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands.\n> > Invalid values, such as those with letters, now trigger error messages\n> > and prevent malformed status responses.\n> >\n> > - Remarks: In this patch series, I learnt a lot of things. The\n> > importance of splitting large changes into Smaller changes for easy\n> > review. I also learnt about how to submit multiple patches which are\n> > not related by creating a new branch from origin/master. Also, I\n> > learnt how to write better commit messages. And lastly, the importance\n> > of asking for help and integrating suggestions from the community.\n> >\n> > I also had the opportunity to review a patch and also answer doubt\n> > from other outreachy applicant mate\n>\n> Nit: s/outreachy/Outreachy/\n>\n> > https://public-inbox.org/git/CAEqABkKvbpo-8-gDpFtfNcpmiC8A5mJMkcDXfhcdNrpwMvBsDA@mail.gmail.com/T/#u\n> > https://public-inbox.org/git/CAPSxiM8SjJwb6x2bhCd4xsYLiNk+KhWYna7-rZhdNGpYNV1tLg@mail.gmail.com/\n> >\n> >\n> > Past experience with other communities\n> > ===============================\n> >\n> > Systemd\n> > ------------\n> >\n> > - I Developed a new unit test framework with assertion macros which\n> > enhanced debugging by providing detailed error reports with file\n> > names, line numbers, and expression values upon failure, improving\n> > issue identification and resolution\n> > - I Updated approximately 22 existing unit test files by modifying 403\n> > lines of code to incorporate the new assertion macros, resulting in\n> > improved logging details and enhanced overall test coverage and\n> > debugging efficiency.\n> > - I Implemented the --json option for the bootctl status command and\n> > updated the integration tests, enabling machine-readable JSON output\n> > for comprehensive bootloader status information\n> >\n> > PR Link:\n> > https://github.com/systemd/systemd/pull/31873\n> > https://github.com/systemd/systemd/pull/31853\n> > https://github.com/systemd/systemd/pull/31819\n> > https://github.com/systemd/systemd/pull/31700\n> > https://github.com/systemd/systemd/pull/31678\n> > https://github.com/systemd/systemd/pull/31669\n> > https://github.com/systemd/systemd/pull/31666\n> > https://github.com/systemd/systemd/pull/32035\n> >\n> > Python Official Documentation\n> > -----------------------------------------\n> > - I have contributed to improving Python's official documentation,\n> > enhancing my Python knowledge, technical writing, and collaboration\n> > skills in open-source.\n> >\n> > PR Link:\n> > https://github.com/python/cpython/pull/109696\n> > https://github.com/python/cpython/pull/111574\n> > https://github.com/python/docs-community/pull/96\n> > https://github.com/python/cpython/pull/113209\n> > https://github.com/python/docs-community/pull/97\n> >\n> > OSIPI (Open Science Initiative for Perfusion Imaging(OSIPI) organization)\n>\n> Nit: s/(OSIPI)//\n>\n> > ---------------------------------------------------------------------------------------------------\n> > - Added a command-line interface to the existing 4D IVIM phantoms\n> > generator, with detailed documentation for usage.\n> > - Created a Python script for efficient reading and writing of NIfTI\n> > images, improving data processing workflows.\n> > - Dockerized the TF2.4_IVIM-MRI_CodeCollection project and implemented\n> > a GitHub Action for automated Docker image building and testing,\n> > ensuring consistent deployment and a streamlined CI/CD pipeline.\n> >\n> > PR Link:\n> > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/92a80d61cfca322da49d126dcd598996fca92668\n> > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/163a187c5eaad33b55a0af0487bd9e19ca520828\n> > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/56ee7173c91c7a1dd64412d3884a3167c7514665\n> > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/e6a47211410ed57705e2ec32adb397ac6663d061\n> > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/60\n> > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/74\n> >\n> > Canonical Docs Website\n> > ---------------------------------\n> > I developed a solution to integrate GitHub contributor information\n> > into Sphinx documentation templates using the GitHub API, enhancing\n> > documentation with contributor insights.\n> >\n> > PR Link:\n> > https://github.com/canonical/sphinx-docs-starter-pack/pull/203#issuecomment-2018521984\n> >\n> > LLVM\n> > --------\n> > I fixed a bug in Clang's Extract API for Objective-C JSON generation\n> > and optimized the test suite within the LLVM Compiler Infrastructure.\n> > https://github.com/Unique-Usman/llvm-project/commit/32b53cf9d0c8c0e01ce5b0e7d5c717202a98cdf5\n> >\n> >\n> > Experience As a user of OpenSource Software\n>\n> Nit: s/As/as/\n>\n> > ====================================\n> >\n> > As an avid user of open-source software, my experience has been\n> > primarily with Linux distributions, particularly Arch, which serves as\n> > my primary operating system. My past usage of Ubuntu has also\n> > contributed to my understanding of different Linux environments.\n> > In addition, I have extensively utilized various free software such as\n> > MySQL for database management, LibreOffice for office productivity,\n> > GCC and G++ for C and C++ programming, Python for scripting and\n> > application development, React for web development, Clang for C/C++\n> > compilation, Git for version control and many others. These\n> > experiences have not only enriched my software knowledge but have also\n> > deepened my understanding of the principles and benefits of\n> > open-source development.\n> >\n> >\n> > —--------------------------------- Project Overview\n> > —--—--------------------------------\n> > In June 2024, a patch series was submitted to the Git mailing list\n> > aimed at adding a new 'os-version' capability to the Git protocol v2.\n> > This capability is designed to allow Git clients and servers to\n> > exchange information about the Operating System (OS) they are using,\n> > which can aid in diagnosing issues and collecting statistical data.\n> > Following the patch submission, discussions arose regarding the\n> > necessary improvements and issues, particularly with Windows\n> > compatibility.\n> > The objective of this internship is to address these outstanding\n> > issues, implement the required improvements, and ensure the successful\n> > integration of the 'os-version' capability into the Git protocol.\n> >\n> > —------- Internship objectives and plans  —-------\n> > The goal of this internship is to finalize the implementation of the\n> > 'os-version' capability in Git protocol v2, as proposed in the patch\n> > series sent to the Git mailing list in June 2024. This enhancement\n> > will allow Git clients and servers to advertise their operating\n> > systems (OS), aiding in diagnostics and data collection.\n> >\n> > Detailed Tasks and Steps\n> > ====================\n> >\n> > Review the Current Patch Series\n> > --------------------------------------------\n> > 1. Examine the Patch: Thoroughly analyze the existing patch series\n> > submitted to the Git mailing list. Understand its design and\n> > functionality, focusing on:\n> >    -  How the OS information is gathered and transmitted.\n> >    -  Current configurations and their implications on data transmission.\n> > 2. Feedback Analysis: Collect feedback from the Git mailing list\n> > discussion regarding the patch. Identify key concerns, especially\n> > related to:\n> >     - Privacy issues.\n> >     - Default behavior expectations.\n> >     - Cross-platform compatibility.\n> > 3. Consider User-Agent Integration: Investigate the suggestion to\n> > integrate the 'os-version' data into the existing user-agent string\n> > rather than creating a new capability. Evaluate:\n> >     - The implications of combining this data with the user-agent.\n> >     - How this approach might address concerns about telemetry and user privacy.\n> >\n> > Implement Default Behavior for 'os-version'\n> > ----------------------------------------------------------\n> > 1. Modify Default Configuration: Adjust the implementation so that by\n> > default, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\n> > communications.\n> > 2. Impact Assessment: Evaluate how this change impacts existing users\n> > and any potential performance implications.\n> >\n> > Introduce a Configuration Variable\n> > ---------------------------------------------\n> > 1. Define Configuration Options\n> >     - Disable Option: Allow users to disable the 'os-version'\n> > capability entirely via configuration.\n> >     - Verbose Option: Enable a verbose mode that sends detailed OS\n> > information (e.g., the output of the uname -srvm command).\n>\n> Shouldn't there be a config option corresponding to the default\n> behavior (which would be to show only the OS Name like \"Linux\",\n> \"Windows\", etc.) ?\n>\n> Also what if users want something more customized, like perhaps \"OS:\n> Linux, Arch: x86_64\"?\nHello Christian,\nthank you very much for the review.\nThis is true, I will add it in the next iteration.\n>\n> > 2. Documentation: Improve the documentation outlining how to enable,\n> > disable, and configure the 'os-version' capability. Include examples\n> > for:\n> >     - Basic usage (default OS name).\n> >     - Detailed usage (full OS version information).\n> > 3. Implementation: Code the configuration settings and ensure they are\n> > recognized by the Git system.\n> >\n> > Fix Cross-Platform Tests\n> > ---------------------------------\n> >\n> > 1. Identify Issues and added tests for changes/addition: Investigate\n> > existing test failures, particularly those occurring on Windows and .\n> >      - Review the test logs and identify the root causes of failures.\n> >      - Analyze differences in OS behaviors and how they affect the tests.\n> >      - Cross-platform tests to validate the functionality on Linux,\n> > Windows, and macOS environments.\n> > 2. Implement Fixes:\n> >       - Modify tests to ensure they run correctly on Windows,\n> > addressing any compatibility issues with the test framework or Git\n> > commands.\n> >       - Ensure all tests reflect the changes made to the OS reporting\n> > capabilities.\n> >\n> > Testing and Validation\n> > ------------------------------\n> > Ensure comprehensive test coverage—including default behavior,\n> > configuration options, and edge cases—integrate tests into the Git CI\n> > pipeline for automatic execution, and share results with the community\n> > for feedback on robustness and additional scenarios.\n> >\n> > Documentation Updates\n> > ---------------------------------\n> >\n> > 1. User Documentation: Update the Git documentation to include:\n> >     - Instructions on how to configure the feature, with practical examples.\n> >     - Best practices regarding data privacy when using the capability.\n> > 2 Developer Documentation: Include comments in the code for\n> > maintainability and understanding of how the 'os-version' capability\n> > works internally.\n> >\n> >  Prepare for Merging\n> > ----------------------------\n> > 1. Final Review: Conduct a thorough review of all code, tests, and\n> > documentation. Ensure everything aligns with Git’s contribution\n> > standards.\n> > 2. Engagement with Community: Present the finalized patch to the Git\n> > mailing list, addressing any additional concerns raised during the\n> > discussions.\n> > 3. Merge Process: Coordinate with the maintainers for merging the\n> > patch into the main branch, ensuring all feedback has been\n> > incorporated.\n> >\n> >\n> > —------------------------- Timeline —-------------------------------------\n> >\n> > Community Feedback and Finalization\n> > =============================\n> > Dates: November 26 - December 8\n> > Engage with the Git community to gather input, especially on privacy\n> > concerns and minimal data sharing. Determine default behavior (sharing\n> > only OS name) and finalize whether to use \"user-agent\" or another\n> > identifier in the protocol(os-version).\n> >\n> > Minimal Default Implementation\n> > ========================\n> > Dates: December 9 - December 20\n> > Implement the core feature to share only the OS name by default,\n> > keeping data minimal as per feedback.\n> >\n> > Configurable Options for OS Version\n> > ============================\n> >\n> > Dates: December 21 - December 30\n> > Develop settings to allow users to disable OS data sharing or choose\n> > verbose mode (e.g., uname -srvm output).\n> >\n> > Cross-Platform Testing (Focus on Windows)\n> > ==================================\n> >\n> > Dates: December 31 - January 13\n> > Conduct robust testing across platforms, addressing prior Windows\n> > compatibility issues.\n> >\n> > Beta Testing and Community Feedback\n> > ==============================\n> > Dates: January 14 - January 27\n> > Release for beta testing, integrate feedback, and refine functionality\n> > based on real-world use.\n> >\n> > Documentation\n> > ============\n> > Dates: January 28 - February 10\n> > Document feature usage, configuration options, and setup instructions\n> > for smooth adoption.\n> >\n> > Final Review and Merge\n> > ===================\n> > Dates: February 11 - March 6\n> > The final review phase will include presenting the completed work to\n> > the Git community for a thorough final assessment. Any remaining\n> > concerns or suggestions will be addressed before the patch is prepared\n> > for merge. This stage will allow for further feedback, particularly\n> > from stakeholders and maintainers who raised the initial questions,\n> > ensuring the solution is acceptable to the broad Git community. Once\n> > consensus is achieved, the patch will be merged into the Git mainline\n> > codebase, concluding the project.\n> >\n> >\n> > Availability\n> > ========\n> > I will be available to work for the required minimum of 30 hours\n> > during the internship period and will be happy to extend if required.\n>\n> Do you mean 30 hours total or 30 hours per week?\nHello Christian,\n\nThanks for your review. I really appreciate it. I meant 30hours per\nweek. I am able to give 40hours per week also, but, I wrote this in\nregards to a comment from Patrick.\nI will send an update proposal with the changes you mentioned.\nUsman Akinyemi.\n>\n> > Blogging\n> > =======\n> > I also plan to keep writing blogs after two weeks, to track my\n> > progress,  give updates about what I am currently working on and also\n> > as a documentation for future contributors.\n> >\n> > Post Outreachy Internship\n> > ====================\n> > One of my dreams is to be an active member of an open-source community\n> > which I can proudly support and contribute to. Continuing my\n> > contributions after the internship is a big part of making that dream\n> > a reality. I’m committed to contributing to Git long-term, helping to\n> > improve the project and supporting new contributors along the way.\n> >\n> > Appreciation\n> > ==========\n> > I really appreciate the support and guidance I got from the git\n>\n> Nit: s/git/Git/\n>\n> > community. I also appreciate all the effort from the outreachy mentor.\n> > Thanks for your time.\n>\n> Thanks,\n> Christian.\n"},{"id":"506209","messageId":"CAPSxiM-EorSBsStHCFAm845q2H+YNDtAvCkwON8cV4AyYvGz_w@mail.gmail.com","threadId":"62413","inReplyTo":"CAPSxiM8NgFUK8R0TrE1nPctOYSD6M8cCe7=xJuniXWO2g-C6Nw@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-10-28T09:27:13Z","receivedAt":"2024-10-28T09:27:26Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"Hello,\nThis is my updated version of my \"Finish adding a 'os-version'\ncapability to Git protocol v2\" proposal based on the comment provided\nby Christian\nThank you.\n\n---------<8----------<8----------<8----------<8----------<8----------<8\n\nPersonal Information\n================\n\nFull Name: Usman Akinyemi\nEmail: usmanakinyemi202@gmail.com\nPersonal Blog: https://uniqueusman.hashnode.dev/\nPersonal Website: https://uniqueusman.tech\nGitHub: https://github.com/Unique-Usman\nDegree: Bachelor of Technology (B.Tech) in Computer Science and\nArtificial Intelligence\n\n\nAbout Me\n========\n\nI am Usman Akinyemi, I often like to refer to myself as a nomadic\ncomputer programmer as I love the ability to work on interesting\nprojects without being restricted to a physical location. I love the\nLinux Operating System and most people already alias my name to Linux\nas I also preach it to everyone everyday. I learnt programming in\nmultiple places, in college,  ALX Software Engineering program and\nalso personal studying. I have decent experience in contributing to\nOpenSource projects. I have contributed to systemd, Cpython\ndocumentation, Canonical website,  pep8speaks and Open Science\nInitiative for Perfusion Imaging (OSIPI). Being someone who is a\nproduct of the community, I value community development so much. I\nhave always tried my best to contribute to the community in my own\nway. One case is when I organized a month-long program(structured\nwebinar) aimed at exposing young Nigerians to opportunities in tech.\nThe program focuses on topics such as OpenSource contributions,\nsecuring internships, career development, freelancing, datascience,\nand introduction to Github and Linux([ Youtube Recording\n]https://www.youtube.com/watch?v=OrAThr-84t8&list=PLBW_HlYT-kP1tUqbzavMAq-ZZQRhMkZH2&ab_channel=UsmanAkinyemi\n). I have also volunteered for different communities one of which is\nDesignIT where we train Nigerian youth on technology.\n\n\nPast Experience with Git\n===================\nI have been a Git user for about three years now. I mainly use git for\npersonal projects, Group projects and OpenSource contributions. I have\nalso had the opportunity to introduce and teach people to Git. I am\nreally excited to be here in the Git community.\nDuring the contribution stage, I have got more familiar with the\ncommunity and how to send patches to Git with the help of the Git\ncommunity. I have also learnt a couple of things, one of which is Git\ncontributor best practices.\n\n\nContributions to the Git Community\n===========================\n\nI joined the Git community after I got selected for Outreachy\nContribution Phase and I have been able to send some patches to the\nGit codebase with the help of the Git community while also learning.\nBelow is the list of my contributions:\n\nMICROPROJECT\n------------------------\n- Link: https://public-inbox.org/git/pull.1805.git.git.1728192814.gitgitgadget@gmail.com/T/#u\n- Branch Name: ua/t3404-cleanup\n- Status: merged into next/jch\n\n+ [PATCH v7 1/2] t3404: avoid losing exit status with focus on `git\nshow` and `git cat-file`\n- Description: In the Git t3404 test script, I improved error\ndetection by restructuring command chains to ensure accurate exit\nstatus handling, preventing missed errors from piped commands.\nThe exit code of the preceding command in a pipe is disregarded. So if\nthat preceding command is a Git command that fails, the test would not\nfail. Instead, by saving the output of that Git command to a file, and\nremoving the pipe, we make sure the test will fail if that Git\ncommand fails. This particular patch focuses on all `git show` and\nsome instances of `git cat-file`.\n\n+ [PATCH v7 2/2] t3404: replace test with test_line_count()\n- Description: Refactor t3404 to replace instances of `test` with\n`test_line_count()` for checking line counts. This improves\nreadability and aligns with Git's current test practices.\n\n- Remarks: Through this process, I deepened my understanding of shell\nscripting and command chaining, focusing on how exit statuses affect\ntesting accuracy. My mentors suggested keeping commands readable and\nconsistent with Git's scripting standards, emphasizing simplicity and\nfuture maintainability. The result is a more robust, reliable test\nscript that better aligns with Git’s best practices, improving overall\ntest suite integrity. Also, through this patch, I was able to\nunderstand the workflow involved in submitting a patch to Git which is\nquite different from many other projects which I have worked on. This\nis really an interesting learning experience.\nI also learnt about the importance of following Git’s best practices\nand also how to submit patches with multiple commits.\n\nLeftOverbits\n-----------------\n- Link: https://public-inbox.org/git/pull.1810.v3.git.git.1729574624.gitgitgadget@gmail.com/T/#t\n- Branch: ua/atoi\n- Status: merged into next/jch\n\nAfter completing the microproject, I wanted to gain a deeper\nunderstanding of Git’s codebase and workflow. I began looking through\nleftoverbits to work on and found a suitable one. Through this, I\nlearned how to add tests for my code additions, which helped me\nunderstand the process of integrating and validating changes in the\ncodebase.\n\n- General Description: In this series of patches, I replaced `atoi()`\nwith `strtoul_ui()` and `strtol_i()` across the daemon, merge, and\nIMAP components to address the issue of inadequate error handling and\ninput validation. The use of `atoi()` could lead to undefined behavior\nwhen parsing invalid inputs, such as letters, which might result in\nincorrect program behavior. Now, invalid inputs trigger clear error\nmessages, ensuring safer parsing and preventing malformed responses. I\nupdated tests for the daemon and merged components to verify these\nimprovements, while IMAP changes didn't include tests since none\nexisted for `git-imap-send`. Overall, this update significantly\nstrengthens input validation and code reliability.\n\n+ [PATCH v6 1/3] daemon: replace atoi() with strtoul_ui() and strtol_i()\nReplace atoi() with strtoul_ui() for --timeout and --init-timeout\n(non-negative integers) and with strtol_i() for --max-connections\n(signed integers). This improves error handling and input validation\nby detecting invalid values and providing clear error messages.\n\n+ [PATCH v6 2/3] merge: replace atoi() with strtol_i() for marker size\nvalidation\nReplace atoi() with strtol_i() for parsing conflict-marker-size to\nimprove error handling. Invalid values, such as those containing\nletters now trigger a clear error message.\n\n+ [PATCH v6 3/3] imap: replace atoi() with strtol_i() for UIDVALIDITY\nand UIDNEXT\nReplace unsafe uses of atoi() with strtol_i() to improve error handling\nwhen parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands.\nInvalid values, such as those with letters, now trigger error messages\nand prevent malformed status responses.\n\n- Remarks: In this patch series, I learnt a lot of things. The\nimportance of splitting large changes into Smaller changes for easy\nreview. I also learnt about how to submit multiple patches which are\nnot related by creating a new branch from origin/master. Also, I\nlearnt how to write better commit messages. And lastly, the importance\nof asking for help and integrating suggestions from the community.\n\nI also had the opportunity to review a patch and also answer doubt\nfrom other Outreachy applicant mate\nhttps://public-inbox.org/git/CAEqABkKvbpo-8-gDpFtfNcpmiC8A5mJMkcDXfhcdNrpwMvBsDA@mail.gmail.com/T/#u\nhttps://public-inbox.org/git/CAPSxiM8SjJwb6x2bhCd4xsYLiNk+KhWYna7-rZhdNGpYNV1tLg@mail.gmail.com/\n\n\nPast experience with other communities\n===============================\n\nSystemd\n------------\n\n- I Developed a new unit test framework with assertion macros which\nenhanced debugging by providing detailed error reports with file\nnames, line numbers, and expression values upon failure, improving\nissue identification and resolution\n- I Updated approximately 22 existing unit test files by modifying 403\nlines of code to incorporate the new assertion macros, resulting in\nimproved logging details and enhanced overall test coverage and\ndebugging efficiency.\n- I Implemented the --json option for the bootctl status command and\nupdated the integration tests, enabling machine-readable JSON output\nfor comprehensive bootloader status information\n\nPR Link:\nhttps://github.com/systemd/systemd/pull/31873\nhttps://github.com/systemd/systemd/pull/31853\nhttps://github.com/systemd/systemd/pull/31819\nhttps://github.com/systemd/systemd/pull/31700\nhttps://github.com/systemd/systemd/pull/31678\nhttps://github.com/systemd/systemd/pull/31669\nhttps://github.com/systemd/systemd/pull/31666\nhttps://github.com/systemd/systemd/pull/32035\n\nPython Official Documentation\n-----------------------------------------\n- I have contributed to improving Python's official documentation,\nenhancing my Python knowledge, technical writing, and collaboration\nskills in open-source.\n\nPR Link:\nhttps://github.com/python/cpython/pull/109696\nhttps://github.com/python/cpython/pull/111574\nhttps://github.com/python/docs-community/pull/96\nhttps://github.com/python/cpython/pull/113209\nhttps://github.com/python/docs-community/pull/97\n\nOSIPI (Open Science Initiative for Perfusion Imaging organization)\n---------------------------------------------------------------------------------------------------\n- Added a command-line interface to the existing 4D IVIM phantoms\ngenerator, with detailed documentation for usage.\n- Created a Python script for efficient reading and writing of NIfTI\nimages, improving data processing workflows.\n- Dockerized the TF2.4_IVIM-MRI_CodeCollection project and implemented\na GitHub Action for automated Docker image building and testing,\nensuring consistent deployment and a streamlined CI/CD pipeline.\n\nPR Link:\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/92a80d61cfca322da49d126dcd598996fca92668\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/163a187c5eaad33b55a0af0487bd9e19ca520828\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/56ee7173c91c7a1dd64412d3884a3167c7514665\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/e6a47211410ed57705e2ec32adb397ac6663d061\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/60\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/74\n\nCanonical Docs Website\n---------------------------------\nI developed a solution to integrate GitHub contributor information\ninto Sphinx documentation templates using the GitHub API, enhancing\ndocumentation with contributor insights.\n\nPR Link:\nhttps://github.com/canonical/sphinx-docs-starter-pack/pull/203#issuecomment-2018521984\n\nLLVM\n--------\nI fixed a bug in Clang's Extract API for Objective-C JSON generation\nand optimized the test suite within the LLVM Compiler Infrastructure.\nhttps://github.com/Unique-Usman/llvm-project/commit/32b53cf9d0c8c0e01ce5b0e7d5c717202a98cdf5\n\n\nExperience as a user of OpenSource Software\n====================================\n\nAs an avid user of open-source software, my experience has been\nprimarily with Linux distributions, particularly Arch, which serves as\nmy primary operating system. My past usage of Ubuntu has also\ncontributed to my understanding of different Linux environments.\nIn addition, I have extensively utilized various free software such as\nMySQL for database management, LibreOffice for office productivity,\nGCC and G++ for C and C++ programming, Python for scripting and\napplication development, React for web development, Clang for C/C++\ncompilation, Git for version control and many others. These\nexperiences have not only enriched my software knowledge but have also\ndeepened my understanding of the principles and benefits of\nopen-source development.\n\n\n—---------------- Project Overview ---------------------------\n\nIn June 2024, a patch series was submitted to the Git mailing list\naimed at adding a new 'os-version' capability to the Git protocol v2.\nThis capability is designed to allow Git clients and servers to\nexchange information about the Operating System (OS) they are using,\nwhich can aid in diagnosing issues and collecting statistical data.\nFollowing the patch submission, discussions arose regarding the\nnecessary improvements and issues, particularly with Windows\ncompatibility.\nThe objective of this internship is to address these outstanding\nissues, implement the required improvements, and ensure the successful\nintegration of the 'os-version' capability into the Git protocol.\n\n—------- Internship objectives and plans  —-------\nThe goal of this internship is to finalize the implementation of the\n'os-version' capability in Git protocol v2, as proposed in the patch\nseries sent to the Git mailing list in June 2024. This enhancement\nwill allow Git clients and servers to advertise their operating\nsystems (OS), aiding in diagnostics and data collection.\n\nDetailed Tasks and Steps\n====================\n\nReview the Current Patch Series\n--------------------------------------------\n1. Examine the Patch: Thoroughly analyze the existing patch series\nsubmitted to the Git mailing list. Understand its design and\nfunctionality, focusing on:\n   -  How the OS information is gathered and transmitted.\n   -  Current configurations and their implications on data transmission.\n2. Feedback Analysis: Collect feedback from the Git mailing list\ndiscussion regarding the patch. Identify key concerns, especially\nrelated to:\n    - Privacy issues.\n    - Default behavior expectations.\n    - Cross-platform compatibility.\n3. Consider User-Agent Integration: Investigate the suggestion to\nintegrate the 'os-version' data into the existing user-agent string\nrather than creating a new capability. Evaluate:\n    - The implications of combining this data with the user-agent.\n    - How this approach might address concerns about telemetry and user privacy.\n\nImplement Default Behavior for 'os-version'\n----------------------------------------------------------\n1. Modify Default Configuration: Adjust the implementation so that by\ndefault, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\ncommunications.\n2. Impact Assessment: Evaluate how this change impacts existing users\nand any potential performance implications.\n\nIntroduce a Configuration Variable\n---------------------------------------------\n1. Define Configuration Options\n    - Disable Option: Allow users to disable the 'os-version'\ncapability entirely via configuration.\n    - Verbose Option: Enable a verbose mode that sends detailed OS\ninformation (e.g., the output of the uname -srvm command).\n    - Custom Option: Allows users to specify components independently,\nusing variables such as $OS_NAME for OS, $DISTRO for Linux\ndistribution, and $ARCH for architecture.\nFor example:\n    i. \"OS: $OS_NAME, Distro: $DISTRO, Arch: $ARCH\" might output \"OS:\nLinux, Distro: Fedora, Arch: x86_64\".\n    ii.  \"Distro: $DISTRO Version, OS: $OS_NAME\" could yield \"Distro:\nUbuntu 22.04, OS: Linux\"\n\n2. Documentation: Improve the documentation outlining how to enable,\ndisable, and configure the 'os-version' capability. Include examples\nfor:\n    - Basic usage (default OS name).\n    - Detailed usage (full OS version information).\n3. Implementation: Code the configuration settings and ensure they are\nrecognized by the Git system.\n\nFix Cross-Platform Tests\n---------------------------------\n\n1. Identify Issues and added tests for changes/addition: Investigate\nexisting test failures, particularly those occurring on Windows and .\n     - Review the test logs and identify the root causes of failures.\n     - Analyze differences in OS behaviors and how they affect the tests.\n     - Cross-platform tests to validate the functionality on Linux,\nWindows, and macOS environments.\n2. Implement Fixes:\n      - Modify tests to ensure they run correctly on Windows,\naddressing any compatibility issues with the test framework or Git\ncommands.\n      - Ensure all tests reflect the changes made to the OS reporting\ncapabilities.\n\nTesting and Validation\n------------------------------\nEnsure comprehensive test coverage—including default behavior,\nconfiguration options, and edge cases—integrate tests into the Git CI\npipeline for automatic execution, and share results with the community\nfor feedback on robustness and additional scenarios.\n\nDocumentation Updates\n---------------------------------\n\n1. User Documentation: Update the Git documentation to include:\n    - Instructions on how to configure the feature, with practical examples.\n    - Best practices regarding data privacy when using the capability.\n2 Developer Documentation: Include comments in the code for\nmaintainability and understanding of how the 'os-version' capability\nworks internally.\n\n Prepare for Merging\n----------------------------\n1. Final Review: Conduct a thorough review of all code, tests, and\ndocumentation. Ensure everything aligns with Git’s contribution\nstandards.\n2. Engagement with Community: Present the finalized patch to the Git\nmailing list, addressing any additional concerns raised during the\ndiscussions.\n3. Merge Process: Coordinate with the maintainers for merging the\npatch into the main branch, ensuring all feedback has been\nincorporated.\n\n\n—------------------------- Timeline —-------------------------------------\n\nCommunity Feedback and Finalization\n=============================\nDates: November 26 - December 8\nEngage with the Git community to gather input, especially on privacy\nconcerns and minimal data sharing. Determine default behavior (sharing\nonly OS name) and finalize whether to use \"user-agent\" or another\nidentifier in the protocol(os-version).\n\nMinimal Default Implementation\n========================\nDates: December 9 - December 20\nImplement the core feature to share only the OS name by default,\nkeeping data minimal as per feedback.\nSend Patches for review from the Git community\n\nConfigurable Options for OS Version\n============================\n\nDates: December 21 - December 30\nDevelop settings to allow users to disable OS data sharing or choose\nverbose mode (e.g., uname -srvm output).\nSend Patches for review from the Git community\n\nCross-Platform Testing (Focus on Windows)\n==================================\n\nDates: December 31 - January 13\nConduct robust testing across platforms, addressing prior Windows\ncompatibility issues.\nSend Patches for review from the Git community\n\nBeta Testing and Community Feedback\n==============================\nDates: January 14 - January 27\nRelease for beta testing, integrate feedback, and refine functionality\nbased on real-world use.\n\nDocumentation\n============\nDates: January 28 - February 10\nDocument feature usage, configuration options, and setup instructions\nfor smooth adoption.\nSend Patches for review from the Git community\n\nFinal Review and Merge\n===================\nDates: February 11 - March 6\nThe final review phase will include presenting the completed work to\nthe Git community for a thorough final assessment. Any remaining\nconcerns or suggestions will be addressed before the patch is prepared\nfor merge. This stage will allow for further feedback, particularly\nfrom stakeholders and maintainers who raised the initial questions,\nensuring the solution is acceptable to the broad Git community. Once\nconsensus is achieved, the patch will be merged into the Git mainline\ncodebase, concluding the project.\n\n\nAvailability\n========\nI will be available to work for the required minimum of 40hours per week\nduring the internship period and will be happy to extend if required.\n\nBlogging\n=======\nI also plan to keep writing blogs after two weeks, to track my\nprogress,  give updates about what I am currently working on and also\nas a documentation for future contributors.\n\nPost Outreachy Internship\n====================\nOne of my dreams is to be an active member of an open-source community\nwhich I can proudly support and contribute to. Continuing my\ncontributions after the internship is a big part of making that dream\na reality. I’m committed to contributing to Git long-term, helping to\nimprove the project and supporting new contributors along the way.\n\nAppreciation\n==========\nI really appreciate the support and guidance I got from the Git\ncommunity. I also appreciate all the effort from the outreachy mentor.\nThanks for your time.\n\nThank you.\nUsman Akinyemi.\n\nOn Mon, Oct 28, 2024 at 9:09 AM Usman Akinyemi\n<usmanakinyemi202@gmail.com> wrote:\n>\n> On Mon, Oct 28, 2024 at 8:26 AM Christian Couder\n> <christian.couder@gmail.com> wrote:\n> >\n> > Hi Usman,\n> >\n> > On Sun, Oct 27, 2024 at 3:54 PM Usman Akinyemi\n> > <usmanakinyemi202@gmail.com> wrote:\n> > >\n> > > Hello Git Community,\n> > >\n> > > I hope this mail finds you well.\n> > >\n> > > This is my proposal for the project \"Finish adding a 'os-version'\n> > > capability to Git protocol v2\" for Outreachy internship program 2024.\n> > >\n> > > I appreciate any feedback on this proposal.\n> >\n> > Thanks for this proposal! You will find my feedback below.\n> >\n> > > ---------<8----------<8----------<8----------<8----------<8----------<8\n> > >\n> > > Personal Information\n> > > ================\n> > >\n> > > Full Name: Usman Akinyemi\n> > > Email: usmanakinyemi202@gmail.com\n> > > Personal Blog: https://uniqueusman.hashnode.dev/\n> > > Personal Website: https://uniqueusman.tech\n> > > GitHub: https://github.com/Unique-Usman\n> > > Degree: Bachelor of Technology (B.Tech) in Computer Science and\n> > > Artificial Intelligence\n> > >\n> > >\n> > > About Me\n> > > ========\n> > >\n> > > I am Usman Akinyemi, I often like to refer to myself as a nomadic\n> > > computer programmer as I love the ability to work on interesting\n> > > projects without being restricted to a physical location. I love the\n> > > Linux Operating System and most people already alias my name to Linux\n> > > as I also preach it to everyone everyday. I learnt programming in\n> > > multiple places, in college,  ALX Software Engineering program and\n> > > also personal studying. I have decent experience in contributing to\n> > > OpenSource projects. I have contributed to systemd, Cpython\n> > > documentation, Canonical website,  pep8speaks and Open Science\n> > > Initiative for Perfusion Imaging (OSIPI). Being someone who is a\n> > > product of the community, I value community development so much. I\n> > > have always tried my best to contribute to the community in my own\n> > > way. One case is when I organized a month-long program(structured\n> > > webinar) aimed at exposing young Nigerians to opportunities in tech.\n> > > The program focuses on topics such as OpenSource contributions,\n> > > securing internships, career development, freelancing, datascience,\n> > > and introduction to Github and Linux([ Youtube Recording\n> > > ]https://www.youtube.com/watch?v=OrAThr-84t8&list=PLBW_HlYT-kP1tUqbzavMAq-ZZQRhMkZH2&ab_channel=UsmanAkinyemi\n> > > ). I have also volunteered for different communities one of which is\n> > > DesignIT where we train Nigerian youth on technology.\n> > >\n> > >\n> > > Past Experience with Git\n> > > ===================\n> > > I have been a Git user for about three years now. I mainly use git for\n> > > personal projects, Group projects and OpenSource contributions. I have\n> > > also had the opportunity to introduce and teach people to Git. I am\n> > > really excited to be here in the Git community.\n> > > During the contribution stage, I have got more familiar with the\n> > > community and how to send patches to Git with the help of the Git\n> > > community. I have also learnt a couple of things, one of which is Git\n> > > contributor best practices.\n> > >\n> > >\n> > > Contributions to the Git Community\n> > > ===========================\n> > >\n> > > I joined the Git community after I got selected for Outreachy\n> > > Contribution Phase and I have been able to send some patches to the\n> > > Git codebase with the help of the Git community while also learning.\n> > > Below is the list of my contributions:\n> > >\n> > > MICROPROJECT\n> > > ------------------------\n> > > - Link: https://public-inbox.org/git/pull.1805.git.git.1728192814.gitgitgadget@gmail.com/T/#u\n> > > - Merge Commit: 6487b2b\n> >\n> > The commit is now 26b7b76329e03252c2738d7af90b5c18db3e98e1. As 'next'\n> > and 'seen' are rebuilt on top of 'master', the commit id changes so it\n> > might be better to just give the branch name, here \"ua/t3404-cleanup\"\n> > for branches that are not yet merged into 'master'.\n> >\n> > > - Status: merged into next/jch\n> >\n> > > + [PATCH v7 1/2] t3404: avoid losing exit status with focus on `git\n> > > show` and `git cat-file`\n> > > - Description: In the Git t3404 test script, I improved error\n> > > detection by restructuring command chains to ensure accurate exit\n> > > status handling, preventing missed errors from piped commands.\n> > > The exit code of the preceding command in a pipe is disregarded. So if\n> > > that preceding command is a Git command that fails, the test would not\n> > > fail. Instead, by saving the output of that Git command to a file, and\n> > > removing the pipe, we make sure the test will fail if that Git\n> > > command fails. This particular patch focuses on all `git show` and\n> > > some instances of `git cat-file`.\n> > >\n> > > + [PATCH v7 2/2] t3404: replace test with test_line_count()\n> > > - Description: Refactor t3404 to replace instances of `test` with\n> > > `test_line_count()` for checking line counts. This improves\n> > > readability and aligns with Git's current test practices.\n> > >\n> > > - Remarks: Through this process, I deepened my understanding of shell\n> > > scripting and command chaining, focusing on how exit statuses affect\n> > > testing accuracy. My mentors suggested keeping commands readable and\n> > > consistent with Git's scripting standards, emphasizing simplicity and\n> > > future maintainability. The result is a more robust, reliable test\n> > > script that better aligns with Git’s best practices, improving overall\n> > > test suite integrity. Also, through this patch, I was able to\n> > > understand the workflow involved in submitting a patch to git which is\n> >\n> > Nit: s/git/Git/\n> >\n> > > quite different from many other projects which I have worked on. This\n> > > is really an interesting learning experience.\n> > > I also learnt about the importance of following Git’s best practices\n> > > and also How  to submit patches with multiple commits.\n> >\n> > Nit: s/How  to/how to/\n> >\n> > > LeftOverbits\n> > > -----------------\n> > > - Link: https://public-inbox.org/git/pull.1810.v3.git.git.1729574624.gitgitgadget@gmail.com/T/#t\n> > > - Merge Commit: cfd82c9\n> >\n> > Here also the merge commit is now\n> > ecd980f7eb8f24fa6ca85e35288d02909b1ba64a, so better just give the\n> > 'ua/atoi' branch name.\n> >\n> > > - Status: merged into next/jch\n> > >\n> > > After completing the microproject, I wanted to gain a deeper\n> > > understanding of Git’s codebase and workflow. I began looking through\n> > > leftoverbits to work on and found a suitable one. Through this, I\n> > > learned how to add tests for my code additions, which helped me\n> > > understand the process of integrating and validating changes in the\n> > > codebase.\n> > >\n> > > - General Description: In this series of patches, I replaced `atoi()`\n> > > with `strtoul_ui()` and `strtol_i()` across the daemon, merge, and\n> > > IMAP components to address the issue of inadequate error handling and\n> > > input validation. The use of `atoi()` could lead to undefined behavior\n> > > when parsing invalid inputs, such as letters, which might result in\n> > > incorrect program behavior. Now, invalid inputs trigger clear error\n> > > messages, ensuring safer parsing and preventing malformed responses. I\n> > > updated tests for the daemon and merged components to verify these\n> > > improvements, while IMAP changes didn't include tests since none\n> > > existed for `git-imap-send`. Overall, this update significantly\n> > > strengthens input validation and code reliability.\n> > >\n> > > + [PATCH v6 1/3] daemon: replace atoi() with strtoul_ui() and strtol_i()\n> > > Replace atoi() with strtoul_ui() for --timeout and --init-timeout\n> > > (non-negative integers) and with strtol_i() for --max-connections\n> > > (signed integers). This improves error handling and input validation\n> > > by detecting invalid values and providing clear error messages.\n> > >\n> > > + [PATCH v6 2/3] merge: replace atoi() with strtol_i() for marker size\n> > > validation\n> > > Replace atoi() with strtol_i() for parsing conflict-marker-size to\n> > > improve error handling. Invalid values, such as those containing\n> > > letters now trigger a clear error message.\n> > >\n> > > + [PATCH v6 3/3] imap: replace atoi() with strtol_i() for UIDVALIDITY\n> > > and UIDNEXT\n> > > Replace unsafe uses of atoi() with strtol_i() to improve error handling\n> > > when parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands.\n> > > Invalid values, such as those with letters, now trigger error messages\n> > > and prevent malformed status responses.\n> > >\n> > > - Remarks: In this patch series, I learnt a lot of things. The\n> > > importance of splitting large changes into Smaller changes for easy\n> > > review. I also learnt about how to submit multiple patches which are\n> > > not related by creating a new branch from origin/master. Also, I\n> > > learnt how to write better commit messages. And lastly, the importance\n> > > of asking for help and integrating suggestions from the community.\n> > >\n> > > I also had the opportunity to review a patch and also answer doubt\n> > > from other outreachy applicant mate\n> >\n> > Nit: s/outreachy/Outreachy/\n> >\n> > > https://public-inbox.org/git/CAEqABkKvbpo-8-gDpFtfNcpmiC8A5mJMkcDXfhcdNrpwMvBsDA@mail.gmail.com/T/#u\n> > > https://public-inbox.org/git/CAPSxiM8SjJwb6x2bhCd4xsYLiNk+KhWYna7-rZhdNGpYNV1tLg@mail.gmail.com/\n> > >\n> > >\n> > > Past experience with other communities\n> > > ===============================\n> > >\n> > > Systemd\n> > > ------------\n> > >\n> > > - I Developed a new unit test framework with assertion macros which\n> > > enhanced debugging by providing detailed error reports with file\n> > > names, line numbers, and expression values upon failure, improving\n> > > issue identification and resolution\n> > > - I Updated approximately 22 existing unit test files by modifying 403\n> > > lines of code to incorporate the new assertion macros, resulting in\n> > > improved logging details and enhanced overall test coverage and\n> > > debugging efficiency.\n> > > - I Implemented the --json option for the bootctl status command and\n> > > updated the integration tests, enabling machine-readable JSON output\n> > > for comprehensive bootloader status information\n> > >\n> > > PR Link:\n> > > https://github.com/systemd/systemd/pull/31873\n> > > https://github.com/systemd/systemd/pull/31853\n> > > https://github.com/systemd/systemd/pull/31819\n> > > https://github.com/systemd/systemd/pull/31700\n> > > https://github.com/systemd/systemd/pull/31678\n> > > https://github.com/systemd/systemd/pull/31669\n> > > https://github.com/systemd/systemd/pull/31666\n> > > https://github.com/systemd/systemd/pull/32035\n> > >\n> > > Python Official Documentation\n> > > -----------------------------------------\n> > > - I have contributed to improving Python's official documentation,\n> > > enhancing my Python knowledge, technical writing, and collaboration\n> > > skills in open-source.\n> > >\n> > > PR Link:\n> > > https://github.com/python/cpython/pull/109696\n> > > https://github.com/python/cpython/pull/111574\n> > > https://github.com/python/docs-community/pull/96\n> > > https://github.com/python/cpython/pull/113209\n> > > https://github.com/python/docs-community/pull/97\n> > >\n> > > OSIPI (Open Science Initiative for Perfusion Imaging(OSIPI) organization)\n> >\n> > Nit: s/(OSIPI)//\n> >\n> > > ---------------------------------------------------------------------------------------------------\n> > > - Added a command-line interface to the existing 4D IVIM phantoms\n> > > generator, with detailed documentation for usage.\n> > > - Created a Python script for efficient reading and writing of NIfTI\n> > > images, improving data processing workflows.\n> > > - Dockerized the TF2.4_IVIM-MRI_CodeCollection project and implemented\n> > > a GitHub Action for automated Docker image building and testing,\n> > > ensuring consistent deployment and a streamlined CI/CD pipeline.\n> > >\n> > > PR Link:\n> > > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/92a80d61cfca322da49d126dcd598996fca92668\n> > > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/163a187c5eaad33b55a0af0487bd9e19ca520828\n> > > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/56ee7173c91c7a1dd64412d3884a3167c7514665\n> > > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/e6a47211410ed57705e2ec32adb397ac6663d061\n> > > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/60\n> > > https://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/74\n> > >\n> > > Canonical Docs Website\n> > > ---------------------------------\n> > > I developed a solution to integrate GitHub contributor information\n> > > into Sphinx documentation templates using the GitHub API, enhancing\n> > > documentation with contributor insights.\n> > >\n> > > PR Link:\n> > > https://github.com/canonical/sphinx-docs-starter-pack/pull/203#issuecomment-2018521984\n> > >\n> > > LLVM\n> > > --------\n> > > I fixed a bug in Clang's Extract API for Objective-C JSON generation\n> > > and optimized the test suite within the LLVM Compiler Infrastructure.\n> > > https://github.com/Unique-Usman/llvm-project/commit/32b53cf9d0c8c0e01ce5b0e7d5c717202a98cdf5\n> > >\n> > >\n> > > Experience As a user of OpenSource Software\n> >\n> > Nit: s/As/as/\n> >\n> > > ====================================\n> > >\n> > > As an avid user of open-source software, my experience has been\n> > > primarily with Linux distributions, particularly Arch, which serves as\n> > > my primary operating system. My past usage of Ubuntu has also\n> > > contributed to my understanding of different Linux environments.\n> > > In addition, I have extensively utilized various free software such as\n> > > MySQL for database management, LibreOffice for office productivity,\n> > > GCC and G++ for C and C++ programming, Python for scripting and\n> > > application development, React for web development, Clang for C/C++\n> > > compilation, Git for version control and many others. These\n> > > experiences have not only enriched my software knowledge but have also\n> > > deepened my understanding of the principles and benefits of\n> > > open-source development.\n> > >\n> > >\n> > > —--------------------------------- Project Overview\n> > > —--—--------------------------------\n> > > In June 2024, a patch series was submitted to the Git mailing list\n> > > aimed at adding a new 'os-version' capability to the Git protocol v2.\n> > > This capability is designed to allow Git clients and servers to\n> > > exchange information about the Operating System (OS) they are using,\n> > > which can aid in diagnosing issues and collecting statistical data.\n> > > Following the patch submission, discussions arose regarding the\n> > > necessary improvements and issues, particularly with Windows\n> > > compatibility.\n> > > The objective of this internship is to address these outstanding\n> > > issues, implement the required improvements, and ensure the successful\n> > > integration of the 'os-version' capability into the Git protocol.\n> > >\n> > > —------- Internship objectives and plans  —-------\n> > > The goal of this internship is to finalize the implementation of the\n> > > 'os-version' capability in Git protocol v2, as proposed in the patch\n> > > series sent to the Git mailing list in June 2024. This enhancement\n> > > will allow Git clients and servers to advertise their operating\n> > > systems (OS), aiding in diagnostics and data collection.\n> > >\n> > > Detailed Tasks and Steps\n> > > ====================\n> > >\n> > > Review the Current Patch Series\n> > > --------------------------------------------\n> > > 1. Examine the Patch: Thoroughly analyze the existing patch series\n> > > submitted to the Git mailing list. Understand its design and\n> > > functionality, focusing on:\n> > >    -  How the OS information is gathered and transmitted.\n> > >    -  Current configurations and their implications on data transmission.\n> > > 2. Feedback Analysis: Collect feedback from the Git mailing list\n> > > discussion regarding the patch. Identify key concerns, especially\n> > > related to:\n> > >     - Privacy issues.\n> > >     - Default behavior expectations.\n> > >     - Cross-platform compatibility.\n> > > 3. Consider User-Agent Integration: Investigate the suggestion to\n> > > integrate the 'os-version' data into the existing user-agent string\n> > > rather than creating a new capability. Evaluate:\n> > >     - The implications of combining this data with the user-agent.\n> > >     - How this approach might address concerns about telemetry and user privacy.\n> > >\n> > > Implement Default Behavior for 'os-version'\n> > > ----------------------------------------------------------\n> > > 1. Modify Default Configuration: Adjust the implementation so that by\n> > > default, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\n> > > communications.\n> > > 2. Impact Assessment: Evaluate how this change impacts existing users\n> > > and any potential performance implications.\n> > >\n> > > Introduce a Configuration Variable\n> > > ---------------------------------------------\n> > > 1. Define Configuration Options\n> > >     - Disable Option: Allow users to disable the 'os-version'\n> > > capability entirely via configuration.\n> > >     - Verbose Option: Enable a verbose mode that sends detailed OS\n> > > information (e.g., the output of the uname -srvm command).\n> >\n> > Shouldn't there be a config option corresponding to the default\n> > behavior (which would be to show only the OS Name like \"Linux\",\n> > \"Windows\", etc.) ?\n> >\n> > Also what if users want something more customized, like perhaps \"OS:\n> > Linux, Arch: x86_64\"?\n> Hello Christian,\n> thank you very much for the review.\n> This is true, I will add it in the next iteration.\n> >\n> > > 2. Documentation: Improve the documentation outlining how to enable,\n> > > disable, and configure the 'os-version' capability. Include examples\n> > > for:\n> > >     - Basic usage (default OS name).\n> > >     - Detailed usage (full OS version information).\n> > > 3. Implementation: Code the configuration settings and ensure they are\n> > > recognized by the Git system.\n> > >\n> > > Fix Cross-Platform Tests\n> > > ---------------------------------\n> > >\n> > > 1. Identify Issues and added tests for changes/addition: Investigate\n> > > existing test failures, particularly those occurring on Windows and .\n> > >      - Review the test logs and identify the root causes of failures.\n> > >      - Analyze differences in OS behaviors and how they affect the tests.\n> > >      - Cross-platform tests to validate the functionality on Linux,\n> > > Windows, and macOS environments.\n> > > 2. Implement Fixes:\n> > >       - Modify tests to ensure they run correctly on Windows,\n> > > addressing any compatibility issues with the test framework or Git\n> > > commands.\n> > >       - Ensure all tests reflect the changes made to the OS reporting\n> > > capabilities.\n> > >\n> > > Testing and Validation\n> > > ------------------------------\n> > > Ensure comprehensive test coverage—including default behavior,\n> > > configuration options, and edge cases—integrate tests into the Git CI\n> > > pipeline for automatic execution, and share results with the community\n> > > for feedback on robustness and additional scenarios.\n> > >\n> > > Documentation Updates\n> > > ---------------------------------\n> > >\n> > > 1. User Documentation: Update the Git documentation to include:\n> > >     - Instructions on how to configure the feature, with practical examples.\n> > >     - Best practices regarding data privacy when using the capability.\n> > > 2 Developer Documentation: Include comments in the code for\n> > > maintainability and understanding of how the 'os-version' capability\n> > > works internally.\n> > >\n> > >  Prepare for Merging\n> > > ----------------------------\n> > > 1. Final Review: Conduct a thorough review of all code, tests, and\n> > > documentation. Ensure everything aligns with Git’s contribution\n> > > standards.\n> > > 2. Engagement with Community: Present the finalized patch to the Git\n> > > mailing list, addressing any additional concerns raised during the\n> > > discussions.\n> > > 3. Merge Process: Coordinate with the maintainers for merging the\n> > > patch into the main branch, ensuring all feedback has been\n> > > incorporated.\n> > >\n> > >\n> > > —------------------------- Timeline —-------------------------------------\n> > >\n> > > Community Feedback and Finalization\n> > > =============================\n> > > Dates: November 26 - December 8\n> > > Engage with the Git community to gather input, especially on privacy\n> > > concerns and minimal data sharing. Determine default behavior (sharing\n> > > only OS name) and finalize whether to use \"user-agent\" or another\n> > > identifier in the protocol(os-version).\n> > >\n> > > Minimal Default Implementation\n> > > ========================\n> > > Dates: December 9 - December 20\n> > > Implement the core feature to share only the OS name by default,\n> > > keeping data minimal as per feedback.\n> > >\n> > > Configurable Options for OS Version\n> > > ============================\n> > >\n> > > Dates: December 21 - December 30\n> > > Develop settings to allow users to disable OS data sharing or choose\n> > > verbose mode (e.g., uname -srvm output).\n> > >\n> > > Cross-Platform Testing (Focus on Windows)\n> > > ==================================\n> > >\n> > > Dates: December 31 - January 13\n> > > Conduct robust testing across platforms, addressing prior Windows\n> > > compatibility issues.\n> > >\n> > > Beta Testing and Community Feedback\n> > > ==============================\n> > > Dates: January 14 - January 27\n> > > Release for beta testing, integrate feedback, and refine functionality\n> > > based on real-world use.\n> > >\n> > > Documentation\n> > > ============\n> > > Dates: January 28 - February 10\n> > > Document feature usage, configuration options, and setup instructions\n> > > for smooth adoption.\n> > >\n> > > Final Review and Merge\n> > > ===================\n> > > Dates: February 11 - March 6\n> > > The final review phase will include presenting the completed work to\n> > > the Git community for a thorough final assessment. Any remaining\n> > > concerns or suggestions will be addressed before the patch is prepared\n> > > for merge. This stage will allow for further feedback, particularly\n> > > from stakeholders and maintainers who raised the initial questions,\n> > > ensuring the solution is acceptable to the broad Git community. Once\n> > > consensus is achieved, the patch will be merged into the Git mainline\n> > > codebase, concluding the project.\n> > >\n> > >\n> > > Availability\n> > > ========\n> > > I will be available to work for the required minimum of 30 hours\n> > > during the internship period and will be happy to extend if required.\n> >\n> > Do you mean 30 hours total or 30 hours per week?\n> Hello Christian,\n>\n> Thanks for your review. I really appreciate it. I meant 30hours per\n> week. I am able to give 40hours per week also, but, I wrote this in\n> regards to a comment from Patrick.\n> I will send an update proposal with the changes you mentioned.\n> Usman Akinyemi.\n> >\n> > > Blogging\n> > > =======\n> > > I also plan to keep writing blogs after two weeks, to track my\n> > > progress,  give updates about what I am currently working on and also\n> > > as a documentation for future contributors.\n> > >\n> > > Post Outreachy Internship\n> > > ====================\n> > > One of my dreams is to be an active member of an open-source community\n> > > which I can proudly support and contribute to. Continuing my\n> > > contributions after the internship is a big part of making that dream\n> > > a reality. I’m committed to contributing to Git long-term, helping to\n> > > improve the project and supporting new contributors along the way.\n> > >\n> > > Appreciation\n> > > ==========\n> > > I really appreciate the support and guidance I got from the git\n> >\n> > Nit: s/git/Git/\n> >\n> > > community. I also appreciate all the effort from the outreachy mentor.\n> > > Thanks for your time.\n> >\n> > Thanks,\n> > Christian.\n"},{"id":"506272","messageId":"CAP8UFD15F2bdQakdEK2K195FV5QrK+9Kw8Z2svysAjNGGL0Jmw@mail.gmail.com","threadId":"62413","inReplyTo":"CAPSxiM-EorSBsStHCFAm845q2H+YNDtAvCkwON8cV4AyYvGz_w@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-10-29T09:13:41Z","receivedAt":"2024-10-29T09:13:55Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Mon, Oct 28, 2024 at 10:27 AM Usman Akinyemi\n<usmanakinyemi202@gmail.com> wrote:\n\n> Review the Current Patch Series\n> --------------------------------------------\n> 1. Examine the Patch: Thoroughly analyze the existing patch series\n> submitted to the Git mailing list. Understand its design and\n> functionality, focusing on:\n>    -  How the OS information is gathered and transmitted.\n>    -  Current configurations and their implications on data transmission.\n> 2. Feedback Analysis: Collect feedback from the Git mailing list\n> discussion regarding the patch. Identify key concerns, especially\n> related to:\n>     - Privacy issues.\n>     - Default behavior expectations.\n>     - Cross-platform compatibility.\n> 3. Consider User-Agent Integration: Investigate the suggestion to\n> integrate the 'os-version' data into the existing user-agent string\n> rather than creating a new capability. Evaluate:\n>     - The implications of combining this data with the user-agent.\n>     - How this approach might address concerns about telemetry and user privacy.\n>\n> Implement Default Behavior for 'os-version'\n> ----------------------------------------------------------\n> 1. Modify Default Configuration: Adjust the implementation so that by\n> default, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\n> communications.\n> 2. Impact Assessment: Evaluate how this change impacts existing users\n> and any potential performance implications.\n>\n> Introduce a Configuration Variable\n> ---------------------------------------------\n> 1. Define Configuration Options\n>     - Disable Option: Allow users to disable the 'os-version'\n> capability entirely via configuration.\n>     - Verbose Option: Enable a verbose mode that sends detailed OS\n> information (e.g., the output of the uname -srvm command).\n>     - Custom Option: Allows users to specify components independently,\n> using variables such as $OS_NAME for OS, $DISTRO for Linux\n> distribution, and $ARCH for architecture.\n> For example:\n>     i. \"OS: $OS_NAME, Distro: $DISTRO, Arch: $ARCH\" might output \"OS:\n> Linux, Distro: Fedora, Arch: x86_64\".\n>     ii.  \"Distro: $DISTRO Version, OS: $OS_NAME\" could yield \"Distro:\n> Ubuntu 22.04, OS: Linux\"\n\nDo you have ideas about how this configuration variable could be\nnamed? An example of what the doc for it could look like?\n\nI haven't looked much into it, so I don't know what's best, but for a\ncustom option, an alternative to using $OS_NAME, $DISTRO, $ARCH, etc,\nmight be to use things like %(os_name), %(distro), %(arch), etc which\nare used in ref-filter formats (see git for-each-ref documentation).\n\n> 2. Documentation: Improve the documentation outlining how to enable,\n> disable, and configure the 'os-version' capability. Include examples\n> for:\n>     - Basic usage (default OS name).\n>     - Detailed usage (full OS version information).\n> 3. Implementation: Code the configuration settings and ensure they are\n> recognized by the Git system.\n>\n> Fix Cross-Platform Tests\n> ---------------------------------\n>\n> 1. Identify Issues and added tests for changes/addition: Investigate\n> existing test failures, particularly those occurring on Windows and .\n>      - Review the test logs and identify the root causes of failures.\n>      - Analyze differences in OS behaviors and how they affect the tests.\n>      - Cross-platform tests to validate the functionality on Linux,\n> Windows, and macOS environments.\n\nIt might be nice to explain how you plan to test on different platforms.\n\n> 2. Implement Fixes:\n>       - Modify tests to ensure they run correctly on Windows,\n> addressing any compatibility issues with the test framework or Git\n> commands.\n>       - Ensure all tests reflect the changes made to the OS reporting\n> capabilities.\n>\n> Testing and Validation\n> ------------------------------\n> Ensure comprehensive test coverage—including default behavior,\n> configuration options, and edge cases—integrate tests into the Git CI\n> pipeline for automatic execution, and share results with the community\n> for feedback on robustness and additional scenarios.\n>\n> Documentation Updates\n> ---------------------------------\n>\n> 1. User Documentation: Update the Git documentation to include:\n>     - Instructions on how to configure the feature, with practical examples.\n>     - Best practices regarding data privacy when using the capability.\n> 2 Developer Documentation: Include comments in the code for\n> maintainability and understanding of how the 'os-version' capability\n> works internally.\n>\n>  Prepare for Merging\n> ----------------------------\n> 1. Final Review: Conduct a thorough review of all code, tests, and\n> documentation. Ensure everything aligns with Git’s contribution\n> standards.\n> 2. Engagement with Community: Present the finalized patch to the Git\n> mailing list, addressing any additional concerns raised during the\n> discussions.\n> 3. Merge Process: Coordinate with the maintainers for merging the\n> patch into the main branch, ensuring all feedback has been\n> incorporated.\n>\n>\n> —------------------------- Timeline —-------------------------------------\n>\n> Community Feedback and Finalization\n> =============================\n> Dates: November 26 - December 8\n> Engage with the Git community to gather input, especially on privacy\n> concerns and minimal data sharing. Determine default behavior (sharing\n> only OS name) and finalize whether to use \"user-agent\" or another\n> identifier in the protocol(os-version).\n>\n> Minimal Default Implementation\n> ========================\n> Dates: December 9 - December 20\n> Implement the core feature to share only the OS name by default,\n> keeping data minimal as per feedback.\n> Send Patches for review from the Git community\n>\n> Configurable Options for OS Version\n> ============================\n>\n> Dates: December 21 - December 30\n> Develop settings to allow users to disable OS data sharing or choose\n> verbose mode (e.g., uname -srvm output).\n> Send Patches for review from the Git community\n\nMy opinion is that disabling OS data sharing will be required from the\nstart, while choosing a verbose mode or a custom mode could be\ndeveloped afterwards. So I think steps like the following make more\nsense:\n\n1. Implement the core feature to share only the OS name by default, as\nwell as an option to disable that feature.\n2. Implement a verbose mode.\n3. Implement a custom mode.\n\n> Cross-Platform Testing (Focus on Windows)\n> ==================================\n>\n> Dates: December 31 - January 13\n> Conduct robust testing across platforms, addressing prior Windows\n> compatibility issues.\n> Send Patches for review from the Git community\n\nMy opinion is that testing on all the platforms will be required for\neach step, so that cannot be left for a later step. It should be\nintegrated into each of the development steps.\n\n> Beta Testing and Community Feedback\n> ==============================\n> Dates: January 14 - January 27\n> Release for beta testing, integrate feedback, and refine functionality\n> based on real-world use.\n\nThis should also be part of each of the development steps.\n\nAlso new features often spend some time in the 'next' branch before\nbeing merged to master, which might be considered some kind of beta\ntesting, but we don't call it \"beta testing\". Before a new release is\ntagged, we have a few rc0, rc1, etc releases, but they are not called\n\"beta\" releases either. They are actually called \"rc\" releases, \"rc\"\nmeaning \"Release Candidate\". So overall, to avoid confusion, I think\nit's better to not use the \"beta testing\" term unless you explicitly\nsay what you mean by it.\n\n> Documentation\n> ============\n> Dates: January 28 - February 10\n> Document feature usage, configuration options, and setup instructions\n> for smooth adoption.\n> Send Patches for review from the Git community\n\nDocumentation should also be part of each of the development steps.\n\n> Final Review and Merge\n> ===================\n> Dates: February 11 - March 6\n> The final review phase will include presenting the completed work to\n> the Git community for a thorough final assessment. Any remaining\n> concerns or suggestions will be addressed before the patch is prepared\n> for merge. This stage will allow for further feedback, particularly\n> from stakeholders and maintainers who raised the initial questions,\n> ensuring the solution is acceptable to the broad Git community. Once\n> consensus is achieved, the patch will be merged into the Git mainline\n> codebase, concluding the project.\n\nNot sure how things will go with reviews, but we prefer if development\ncan be incremental. So I hope some initial patches will be merged well\nbefore the end of the internship.\n\n> Availability\n> ========\n> I will be available to work for the required minimum of 40hours per week\n> during the internship period and will be happy to extend if required.\n>\n> Blogging\n> =======\n> I also plan to keep writing blogs after two weeks, to track my\n> progress,  give updates about what I am currently working on and also\n> as a documentation for future contributors.\n>\n> Post Outreachy Internship\n> ====================\n> One of my dreams is to be an active member of an open-source community\n> which I can proudly support and contribute to. Continuing my\n> contributions after the internship is a big part of making that dream\n> a reality. I’m committed to contributing to Git long-term, helping to\n> improve the project and supporting new contributors along the way.\n>\n> Appreciation\n> ==========\n> I really appreciate the support and guidance I got from the Git\n> community. I also appreciate all the effort from the outreachy mentor.\n> Thanks for your time.\n\nThanks for your application!\n\n> On Mon, Oct 28, 2024 at 9:09 AM Usman Akinyemi\n> <usmanakinyemi202@gmail.com> wrote:\n> >\n> > On Mon, Oct 28, 2024 at 8:26 AM Christian Couder\n> > <christian.couder@gmail.com> wrote:\n\nPlease remove previous discussions you don't reply to at the bottom of\nyour emails.\n\nThanks,\nChristian.\n"},{"id":"506274","messageId":"CAPSxiM_JCGtkcaxRN8+=cOCgpWtWZPC8W=Wv23dCcV_g-wwwPg@mail.gmail.com","threadId":"62413","inReplyTo":"CAP8UFD15F2bdQakdEK2K195FV5QrK+9Kw8Z2svysAjNGGL0Jmw@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-10-29T09:52:04Z","receivedAt":"2024-10-29T09:52:17Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Tue, Oct 29, 2024 at 9:13 AM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi,\n>\n> On Mon, Oct 28, 2024 at 10:27 AM Usman Akinyemi\n> <usmanakinyemi202@gmail.com> wrote:\n>\n> > Review the Current Patch Series\n> > --------------------------------------------\n> > 1. Examine the Patch: Thoroughly analyze the existing patch series\n> > submitted to the Git mailing list. Understand its design and\n> > functionality, focusing on:\n> >    -  How the OS information is gathered and transmitted.\n> >    -  Current configurations and their implications on data transmission.\n> > 2. Feedback Analysis: Collect feedback from the Git mailing list\n> > discussion regarding the patch. Identify key concerns, especially\n> > related to:\n> >     - Privacy issues.\n> >     - Default behavior expectations.\n> >     - Cross-platform compatibility.\n> > 3. Consider User-Agent Integration: Investigate the suggestion to\n> > integrate the 'os-version' data into the existing user-agent string\n> > rather than creating a new capability. Evaluate:\n> >     - The implications of combining this data with the user-agent.\n> >     - How this approach might address concerns about telemetry and user privacy.\n> >\n> > Implement Default Behavior for 'os-version'\n> > ----------------------------------------------------------\n> > 1. Modify Default Configuration: Adjust the implementation so that by\n> > default, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\n> > communications.\n> > 2. Impact Assessment: Evaluate how this change impacts existing users\n> > and any potential performance implications.\n> >\n> > Introduce a Configuration Variable\n> > ---------------------------------------------\n> > 1. Define Configuration Options\n> >     - Disable Option: Allow users to disable the 'os-version'\n> > capability entirely via configuration.\n> >     - Verbose Option: Enable a verbose mode that sends detailed OS\n> > information (e.g., the output of the uname -srvm command).\n> >     - Custom Option: Allows users to specify components independently,\n> > using variables such as $OS_NAME for OS, $DISTRO for Linux\n> > distribution, and $ARCH for architecture.\n> > For example:\n> >     i. \"OS: $OS_NAME, Distro: $DISTRO, Arch: $ARCH\" might output \"OS:\n> > Linux, Distro: Fedora, Arch: x86_64\".\n> >     ii.  \"Distro: $DISTRO Version, OS: $OS_NAME\" could yield \"Distro:\n> > Ubuntu 22.04, OS: Linux\"\n>\n> Do you have ideas about how this configuration variable could be\n> named? An example of what the doc for it could look like?\n>\n> I haven't looked much into it, so I don't know what's best, but for a\n> custom option, an alternative to using $OS_NAME, $DISTRO, $ARCH, etc,\n> might be to use things like %(os_name), %(distro), %(arch), etc which\n> are used in ref-filter formats (see git for-each-ref documentation).\n>\nHi Christian,\nI think going with the one in git for-each-ref is better for\nconsistency across Git.\n> > 2. Documentation: Improve the documentation outlining how to enable,\n> > disable, and configure the 'os-version' capability. Include examples\n> > for:\n> >     - Basic usage (default OS name).\n> >     - Detailed usage (full OS version information).\n> > 3. Implementation: Code the configuration settings and ensure they are\n> > recognized by the Git system.\n> >\n> > Fix Cross-Platform Tests\n> > ---------------------------------\n> >\n> > 1. Identify Issues and added tests for changes/addition: Investigate\n> > existing test failures, particularly those occurring on Windows and .\n> >      - Review the test logs and identify the root causes of failures.\n> >      - Analyze differences in OS behaviors and how they affect the tests.\n> >      - Cross-platform tests to validate the functionality on Linux,\n> > Windows, and macOS environments.\n>\n> It might be nice to explain how you plan to test on different platforms.\nNoted, I will do that.\n>\n> > 2. Implement Fixes:\n> >       - Modify tests to ensure they run correctly on Windows,\n> > addressing any compatibility issues with the test framework or Git\n> > commands.\n> >       - Ensure all tests reflect the changes made to the OS reporting\n> > capabilities.\n> >\n> > Testing and Validation\n> > ------------------------------\n> > Ensure comprehensive test coverage—including default behavior,\n> > configuration options, and edge cases—integrate tests into the Git CI\n> > pipeline for automatic execution, and share results with the community\n> > for feedback on robustness and additional scenarios.\n> >\n> > Documentation Updates\n> > ---------------------------------\n> >\n> > 1. User Documentation: Update the Git documentation to include:\n> >     - Instructions on how to configure the feature, with practical examples.\n> >     - Best practices regarding data privacy when using the capability.\n> > 2 Developer Documentation: Include comments in the code for\n> > maintainability and understanding of how the 'os-version' capability\n> > works internally.\n> >\n> >  Prepare for Merging\n> > ----------------------------\n> > 1. Final Review: Conduct a thorough review of all code, tests, and\n> > documentation. Ensure everything aligns with Git’s contribution\n> > standards.\n> > 2. Engagement with Community: Present the finalized patch to the Git\n> > mailing list, addressing any additional concerns raised during the\n> > discussions.\n> > 3. Merge Process: Coordinate with the maintainers for merging the\n> > patch into the main branch, ensuring all feedback has been\n> > incorporated.\n> >\n> >\n> > —------------------------- Timeline —-------------------------------------\n> >\n> > Community Feedback and Finalization\n> > =============================\n> > Dates: November 26 - December 8\n> > Engage with the Git community to gather input, especially on privacy\n> > concerns and minimal data sharing. Determine default behavior (sharing\n> > only OS name) and finalize whether to use \"user-agent\" or another\n> > identifier in the protocol(os-version).\n> >\n> > Minimal Default Implementation\n> > ========================\n> > Dates: December 9 - December 20\n> > Implement the core feature to share only the OS name by default,\n> > keeping data minimal as per feedback.\n> > Send Patches for review from the Git community\n> >\n> > Configurable Options for OS Version\n> > ============================\n> >\n> > Dates: December 21 - December 30\n> > Develop settings to allow users to disable OS data sharing or choose\n> > verbose mode (e.g., uname -srvm output).\n> > Send Patches for review from the Git community\n>\n> My opinion is that disabling OS data sharing will be required from the\n> start, while choosing a verbose mode or a custom mode could be\n> developed afterwards. So I think steps like the following make more\n> sense:\n>\n> 1. Implement the core feature to share only the OS name by default, as\n> well as an option to disable that feature.\n> 2. Implement a verbose mode.\n> 3. Implement a custom mode.\nNoted, I will change that.\n>\n> > Cross-Platform Testing (Focus on Windows)\n> > ==================================\n> >\n> > Dates: December 31 - January 13\n> > Conduct robust testing across platforms, addressing prior Windows\n> > compatibility issues.\n> > Send Patches for review from the Git community\n>\n> My opinion is that testing on all the platforms will be required for\n> each step, so that cannot be left for a later step. It should be\n> integrated into each of the development steps.\nNoted, I will make changes to that.\n>\n> > Beta Testing and Community Feedback\n> > ==============================\n> > Dates: January 14 - January 27\n> > Release for beta testing, integrate feedback, and refine functionality\n> > based on real-world use.\n>\n> This should also be part of each of the development steps.\nYeah.\n>\n> Also new features often spend some time in the 'next' branch before\n> being merged to master, which might be considered some kind of beta\n> testing, but we don't call it \"beta testing\". Before a new release is\n> tagged, we have a few rc0, rc1, etc releases, but they are not called\n> \"beta\" releases either. They are actually called \"rc\" releases, \"rc\"\n> meaning \"Release Candidate\". So overall, to avoid confusion, I think\n> it's better to not use the \"beta testing\" term unless you explicitly\n> say what you mean by it.\n>\nI will make use of rc here.\n> > Documentation\n> > ============\n> > Dates: January 28 - February 10\n> > Document feature usage, configuration options, and setup instructions\n> > for smooth adoption.\n> > Send Patches for review from the Git community\n>\n> Documentation should also be part of each of the development steps.\nNoted.\n>\n> > Final Review and Merge\n> > ===================\n> > Dates: February 11 - March 6\n> > The final review phase will include presenting the completed work to\n> > the Git community for a thorough final assessment. Any remaining\n> > concerns or suggestions will be addressed before the patch is prepared\n> > for merge. This stage will allow for further feedback, particularly\n> > from stakeholders and maintainers who raised the initial questions,\n> > ensuring the solution is acceptable to the broad Git community. Once\n> > consensus is achieved, the patch will be merged into the Git mainline\n> > codebase, concluding the project.\n>\n> Not sure how things will go with reviews, but we prefer if development\n> can be incremental. So I hope some initial patches will be merged well\n> before the end of the internship.\n>\n> > Availability\n> > ========\n> > I will be available to work for the required minimum of 40hours per week\n> > during the internship period and will be happy to extend if required.\n> >\n> > Blogging\n> > =======\n> > I also plan to keep writing blogs after two weeks, to track my\n> > progress,  give updates about what I am currently working on and also\n> > as a documentation for future contributors.\n> >\n> > Post Outreachy Internship\n> > ====================\n> > One of my dreams is to be an active member of an open-source community\n> > which I can proudly support and contribute to. Continuing my\n> > contributions after the internship is a big part of making that dream\n> > a reality. I’m committed to contributing to Git long-term, helping to\n> > improve the project and supporting new contributors along the way.\n> >\n> > Appreciation\n> > ==========\n> > I really appreciate the support and guidance I got from the Git\n> > community. I also appreciate all the effort from the outreachy mentor.\n> > Thanks for your time.\n>\n> Thanks for your application!\nThank you very much, I really appreciate the review. I will make the changes.\n>\n> > On Mon, Oct 28, 2024 at 9:09 AM Usman Akinyemi\n> > <usmanakinyemi202@gmail.com> wrote:\n> > >\n> > > On Mon, Oct 28, 2024 at 8:26 AM Christian Couder\n> > > <christian.couder@gmail.com> wrote:\n>\n> Please remove previous discussions you don't reply to at the bottom of\n> your emails.\nNoted.\n>\n> Thanks,\n> Christian.\n"},{"id":"506279","messageId":"CAPSxiM_rvt-tkQjHYmYNv-Wyr0=X4+123dt=vZKtc++PGRjQMQ@mail.gmail.com","threadId":"62413","inReplyTo":"CAPSxiM_JCGtkcaxRN8+=cOCgpWtWZPC8W=Wv23dCcV_g-wwwPg@mail.gmail.com","subject":"Re: [Outreachy][proposal]: Finish adding a 'os-version' capability to Git protocol v2","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-10-29T11:50:49Z","receivedAt":"2024-10-29T11:51:01Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"Hello,\nThis is my updated version of my \"Finish adding a 'os-version'\ncapability to Git protocol v2\" proposal based on the comment provided\nby Christian\nThank you.\n\n---------<8----------<8----------<8----------<8----------<8----------<8\n\nPersonal Information\n================\n\nFull Name: Usman Akinyemi\nEmail: usmanakinyemi202@gmail.com\nPersonal Blog: https://uniqueusman.hashnode.dev/\nPersonal Website: https://uniqueusman.tech\nGitHub: https://github.com/Unique-Usman\nDegree: Bachelor of Technology (B.Tech) in Computer Science and\nArtificial Intelligence\n\nAbout Me\n========\n\nI am Usman Akinyemi, I often like to refer to myself as a nomadic\ncomputer programmer as I love the ability to work on interesting\nprojects without being restricted to a physical location. I love the\nLinux Operating System and most people already alias my name to Linux\nas I also preach it to everyone everyday. I learnt programming in\nmultiple places, in college,  ALX Software Engineering program and\nalso personal studying. I have decent experience in contributing to\nOpenSource projects. I have contributed to systemd, Cpython\ndocumentation, Canonical website,  pep8speaks and Open Science\nInitiative for Perfusion Imaging (OSIPI). Being someone who is a\nproduct of the community, I value community development so much. I\nhave always tried my best to contribute to the community in my own\nway. One case is when I organized a month-long program(structured\nwebinar) aimed at exposing young Nigerians to opportunities in tech.\nThe program focuses on topics such as OpenSource contributions,\nsecuring internships, career development, freelancing, datascience,\nand introduction to Github and Linux([ Youtube Recording\n]https://www.youtube.com/watch?v=OrAThr-84t8&list=PLBW_HlYT-kP1tUqbzavMAq-ZZQRhMkZH2&ab_channel=UsmanAkinyemi\n). I have also volunteered for different communities one of which is\nDesignIT where we train Nigerian youth on technology.\n\n\nPast Experience with Git\n===================\nI have been a Git user for about three years now. I mainly use git for\npersonal projects, Group projects and OpenSource contributions. I have\nalso had the opportunity to introduce and teach people to Git. I am\nreally excited to be here in the Git community.\nDuring the contribution stage, I have got more familiar with the\ncommunity and how to send patches to Git with the help of the Git\ncommunity. I have also learnt a couple of things, one of which is Git\ncontributor best practices.\n\n\nContributions to the Git Community\n===========================\n\nI joined the Git community after I got selected for Outreachy\nContribution Phase and I have been able to send some patches to the\nGit codebase with the help of the Git community while also learning.\nBelow is the list of my contributions:\n\nMICROPROJECT\n------------------------\n- Link: https://public-inbox.org/git/pull.1805.git.git.1728192814.gitgitgadget@gmail.com/T/#u\n- Branch Name: ua/t3404-cleanup\n- Status: merged into next/jch\n\n+ [PATCH v7 1/2] t3404: avoid losing exit status with focus on `git\nshow` and `git cat-file`\n- Description: In the Git t3404 test script, I improved error\ndetection by restructuring command chains to ensure accurate exit\nstatus handling, preventing missed errors from piped commands.\nThe exit code of the preceding command in a pipe is disregarded. So if\nthat preceding command is a Git command that fails, the test would not\nfail. Instead, by saving the output of that Git command to a file, and\nremoving the pipe, we make sure the test will fail if that Git\ncommand fails. This particular patch focuses on all `git show` and\nsome instances of `git cat-file`.\n\n+ [PATCH v7 2/2] t3404: replace test with test_line_count()\n- Description: Refactor t3404 to replace instances of `test` with\n`test_line_count()` for checking line counts. This improves\nreadability and aligns with Git's current test practices.\n\n- Remarks: Through this process, I deepened my understanding of shell\nscripting and command chaining, focusing on how exit statuses affect\ntesting accuracy. My mentors suggested keeping commands readable and\nconsistent with Git's scripting standards, emphasizing simplicity and\nfuture maintainability. The result is a more robust, reliable test\nscript that better aligns with Git’s best practices, improving overall\ntest suite integrity. Also, through this patch, I was able to\nunderstand the workflow involved in submitting a patch to Git which is\nquite different from many other projects which I have worked on. This\nis really an interesting learning experience.\nI also learnt about the importance of following Git’s best practices\nand also how to submit patches with multiple commits.\n\nLeftOverbits\n-----------------\n- Link: https://public-inbox.org/git/pull.1810.v3.git.git.1729574624.gitgitgadget@gmail.com/T/#t\n- Branch Name: ua/atoi\n- Status: merged into next/jch\n\nAfter completing the microproject, I wanted to gain a deeper\nunderstanding of Git’s codebase and workflow. I began looking through\nleftoverbits to work on and found a suitable one. Through this, I\nlearned how to add tests for my code additions, which helped me\nunderstand the process of integrating and validating changes in the\ncodebase.\n\n- General Description: In this series of patches, I replaced `atoi()`\nwith `strtoul_ui()` and `strtol_i()` across the daemon, merge, and\nIMAP components to address the issue of inadequate error handling and\ninput validation. The use of `atoi()` could lead to undefined behavior\nwhen parsing invalid inputs, such as letters, which might result in\nincorrect program behavior. Now, invalid inputs trigger clear error\nmessages, ensuring safer parsing and preventing malformed responses. I\nupdated tests for the daemon and merged components to verify these\nimprovements, while IMAP changes didn't include tests since none\nexisted for `git-imap-send`. Overall, this update significantly\nstrengthens input validation and code reliability.\n\n+ [PATCH v6 1/3] daemon: replace atoi() with strtoul_ui() and strtol_i()\nReplace atoi() with strtoul_ui() for --timeout and --init-timeout\n(non-negative integers) and with strtol_i() for --max-connections\n(signed integers). This improves error handling and input validation\nby detecting invalid values and providing clear error messages.\n\n+ [PATCH v6 2/3] merge: replace atoi() with strtol_i() for marker size\nvalidation\nReplace atoi() with strtol_i() for parsing conflict-marker-size to\nimprove error handling. Invalid values, such as those containing\nletters now trigger a clear error message.\n\n+ [PATCH v6 3/3] imap: replace atoi() with strtol_i() for UIDVALIDITY\nand UIDNEXT\nReplace unsafe uses of atoi() with strtol_i() to improve error handling\nwhen parsing UIDVALIDITY, UIDNEXT, and APPENDUID in IMAP commands.\nInvalid values, such as those with letters, now trigger error messages\nand prevent malformed status responses.\n\n- Remarks: In this patch series, I learnt a lot of things. The\nimportance of splitting large changes into Smaller changes for easy\nreview. I also learnt about how to submit multiple patches which are\nnot related by creating a new branch from origin/master. Also, I\nlearnt how to write better commit messages. And lastly, the importance\nof asking for help and integrating suggestions from the community.\n\nI also had the opportunity to review a patch and also answer doubt\nfrom other Outreachy applicant mate\n\nhttps://public-inbox.org/git/CAEqABkKvbpo-8-gDpFtfNcpmiC8A5mJMkcDXfhcdNrpwMvBsDA@mail.gmail.com/T/#u\nhttps://public-inbox.org/git/CAPSxiM8SjJwb6x2bhCd4xsYLiNk+KhWYna7-rZhdNGpYNV1tLg@mail.gmail.com/\n\n\nPast experience with other communities\n===============================\n\nSystemd\n------------\n\n- I Developed a new unit test framework with assertion macros which\nenhanced debugging by providing detailed error reports with file\nnames, line numbers, and expression values upon failure, improving\nissue identification and resolution\n- I Updated approximately 22 existing unit test files by modifying 403\nlines of code to incorporate the new assertion macros, resulting in\nimproved logging details and enhanced overall test coverage and\ndebugging efficiency.\n- I Implemented the --json option for the bootctl status command and\nupdated the integration tests, enabling machine-readable JSON output\nfor comprehensive bootloader status information\n\nPR Link:\nhttps://github.com/systemd/systemd/pull/31873\nhttps://github.com/systemd/systemd/pull/31853\nhttps://github.com/systemd/systemd/pull/31819\nhttps://github.com/systemd/systemd/pull/31700\nhttps://github.com/systemd/systemd/pull/31678\nhttps://github.com/systemd/systemd/pull/31669\nhttps://github.com/systemd/systemd/pull/31666\nhttps://github.com/systemd/systemd/pull/32035\n\nPython Official Documentation\n-----------------------------------------\n- I have contributed to improving Python's official documentation,\nenhancing my Python knowledge, technical writing, and collaboration\nskills in open-source.\n\nPR Link:\nhttps://github.com/python/cpython/pull/109696\nhttps://github.com/python/cpython/pull/111574\nhttps://github.com/python/docs-community/pull/96\nhttps://github.com/python/cpython/pull/113209\nhttps://github.com/python/docs-community/pull/97\n\nOSIPI (Open Science Initiative for Perfusion Imaging organization)\n\n---------------------------------------------------------------------------------------------------\n- Added a command-line interface to the existing 4D IVIM phantoms\ngenerator, with detailed documentation for usage.\n- Created a Python script for efficient reading and writing of NIfTI\nimages, improving data processing workflows.\n- Dockerized the TF2.4_IVIM-MRI_CodeCollection project and implemented\na GitHub Action for automated Docker image building and testing,\nensuring consistent deployment and a streamlined CI/CD pipeline.\n\nPR Link:\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/92a80d61cfca322da49d126dcd598996fca92668\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/163a187c5eaad33b55a0af0487bd9e19ca520828\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/56ee7173c91c7a1dd64412d3884a3167c7514665\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/commit/e6a47211410ed57705e2ec32adb397ac6663d061\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/60\nhttps://github.com/OSIPI/TF2.4_IVIM-MRI_CodeCollection/pull/74\n\nCanonical Docs Website\n---------------------------------\nI developed a solution to integrate GitHub contributor information\ninto Sphinx documentation templates using the GitHub API, enhancing\ndocumentation with contributor insights.\n\nPR Link:\nhttps://github.com/canonical/sphinx-docs-starter-pack/pull/203#issuecomment-2018521984\n\nLLVM\n--------\nI fixed a bug in Clang's Extract API for Objective-C JSON generation\nand optimized the test suite within the LLVM Compiler Infrastructure.\nhttps://github.com/Unique-Usman/llvm-project/commit/32b53cf9d0c8c0e01ce5b0e7d5c717202a98cdf5\n\n\nExperience as a user of OpenSource Software\n====================================\n\nAs an avid user of open-source software, my experience has been\nprimarily with Linux distributions, particularly Arch, which serves as\nmy primary operating system. My past usage of Ubuntu has also\ncontributed to my understanding of different Linux environments.\nIn addition, I have extensively utilized various free software such as\nMySQL for database management, LibreOffice for office productivity,\nGCC and G++ for C and C++ programming, Python for scripting and\napplication development, React for web development, Clang for C/C++\ncompilation, Git for version control and many others. These\nexperiences have not only enriched my software knowledge but have also\ndeepened my understanding of the principles and benefits of\nopen-source development.\n\n\n—---------------- Project Overview ---------------------------\n\nIn June 2024, a patch series was submitted to the Git mailing list\naimed at adding a new 'os-version' capability to the Git protocol v2.\nThis capability is designed to allow Git clients and servers to\nexchange information about the Operating System (OS) they are using,\nwhich can aid in diagnosing issues and collecting statistical data.\nFollowing the patch submission, discussions arose regarding the\nnecessary improvements and issues, particularly with Windows\ncompatibility.\nThe objective of this internship is to address these outstanding\nissues, implement the required improvements, and ensure the successful\nintegration of the 'os-version' capability into the Git protocol.\n\n—------- Internship objectives and plans  —-------\nThe goal of this internship is to finalize the implementation of the\n'os-version' capability in Git protocol v2, as proposed in the patch\nseries sent to the Git mailing list in June 2024. This enhancement\nwill allow Git clients and servers to advertise their operating\nsystems (OS), aiding in diagnostics and data collection.\n\nDetailed Tasks and Steps\n====================\n\nReview the Current Patch Series\n--------------------------------------------\n1. Examine the Patch: Thoroughly analyze the existing patch series\nsubmitted to the Git mailing list. Understand its design and\nfunctionality, focusing on:\n   -  How the OS information is gathered and transmitted.\n   -  Current configurations and their implications on data transmission.\n2. Feedback Analysis: Collect feedback from the Git mailing list\ndiscussion regarding the patch. Identify key concerns, especially\nrelated to:\n    - Privacy issues.\n    - Default behavior expectations.\n    - Cross-platform compatibility.\n3. Consider User-Agent Integration: Investigate the suggestion to\nintegrate the 'os-version' data into the existing user-agent string\nrather than creating a new capability. Evaluate:\n    - The implications of combining this data with the user-agent.\n    - How this approach might address concerns about telemetry and user privacy.\n\nImplement Default Behavior for 'os-version'\n----------------------------------------------------------\n1. Modify Default Configuration: Adjust the implementation so that by\ndefault, only the OS name (e.g., \"Linux\" or \"Windows\") is sent during\ncommunications.\n2. Impact Assessment: Evaluate how this change impacts existing users\nand any potential performance implications.\n\nIntroduce a Configuration Variable\n---------------------------------------------\n1. Define Configuration Options\n    - Disable Option: Allow users to disable the 'os-version'\ncapability entirely via configuration.\n    - Verbose Option: Enable a verbose mode that sends detailed OS\ninformation (e.g., the output of the uname -srvm command).\n    - Custom Option: Allows users to specify components independently,\nusing variables such as %(os_name) for OS,  %(distro) for Linux\ndistribution, and %(arch) for architecture.\nFor example:\n    i. \"OS: %(os_name), Distro: %(distro), Arch: %(arch)\" might output \"OS:\nLinux, Distro: Fedora, Arch: x86_64\".\n    ii.  \"Distro: %(distro) Version, OS: %(os_name)\" could yield \"Distro:\nUbuntu 22.04, OS: Linux\"\nSend Patches for review from the Git community\n\n2. Documentation: Improve the documentation outlining how to enable,\ndisable, and configure the 'os-version' capability. Include examples\nfor:\n    - Basic usage (default OS name).\n    - Detailed usage (full OS version information).\n3. Implementation: Code the configuration settings and ensure they are\nrecognized by the Git system.\n\nFix Cross-Platform Tests\n---------------------------------\n\n1. Identify Issues and added tests for changes/addition: Investigate\nexisting test failures, particularly those occurring on Windows and .\n     - Review the test logs and identify the root causes of failures.\n     - Analyze differences in OS behaviors and how they affect the tests.\n     - Cross-platform tests to validate the functionality on Linux,\nWindows, and macOS environments.\n2. Implement Fixes:\n      - Modify tests to ensure they run correctly on Windows,\naddressing any compatibility issues with the test framework or Git\ncommands.\n      - Ensure all tests reflect the changes made to the OS reporting\ncapabilities.\n\nCross-Platform Testing Approach\n--------------------------------------------\n- To ensure robust compatibility, each development phase includes test\ncoverage across Linux, Windows, and other environments using Git's CI\npipeline. Tests will validate that features work seamlessly across all\nplatforms and that output is consistent across different environments.\n\n- Direct Testing on Windows to address compatibility issues unique to\nWindows and verify expected behavior.\n\n\nTesting and Validation\n------------------------------\nEnsure comprehensive test coverage—including default behavior,\nconfiguration options, and edge cases—integrate tests into the Git CI\npipeline for automatic execution, and share results with the community\nfor feedback on robustness and additional scenarios.\n\nDocumentation Updates\n---------------------------------\n\n1. User Documentation: Update the Git documentation to include:\n    - Instructions on how to configure the feature, with practical examples.\n    - Best practices regarding data privacy when using the capability.\n2 Developer Documentation: Include comments in the code for\nmaintainability and understanding of how the 'os-version' capability\nworks internally.\n\n Prepare for Merging\n----------------------------\n1. Final Review: Conduct a thorough review of all code, tests, and\ndocumentation. Ensure everything aligns with Git’s contribution\nstandards.\n2. Engagement with Community: Present the finalized patch to the Git\nmailing list, addressing any additional concerns raised during the\ndiscussions.\n3. Merge Process: Coordinate with the maintainers for merging the\npatch into the main branch, ensuring all feedback has been\nincorporated.\n\n\n—------------------------- Timeline —-------------------------------------\n\nCommunity Feedback and Finalization\n=============================\nDates: November 26 - December 8\nEngage with the Git community to gather input, especially on privacy\nconcerns and minimal data sharing. Determine default behavior (sharing\nonly OS name) and finalize whether to use \"user-agent\" or another\nidentifier in the protocol(os-version).\n\nPreparation and Understanding\n========================\nDates: December 9 - December 12\n- Retrieve patches and create a dedicated branch for this work.\n- Set up a blog post to document the internship experience,\nwith an overview of project goals and initial reflections.\n\nInitial Testing and Patching\n=====================\nDates: December 13 - December 17\nApply patches to establish the foundation for further feature development.\nRun initial tests on the patched branch.\nIdentify current issues, with an emphasis on Windows\ncompatibility challenges and cross-platform stability.\n\nIncremental Development with Testing, Documentation, and Release Candidates (RC)\n=================================================================\nDates: December 18 - February 24\nEach feature development phase will follow an incremental approach,\nwhere implementation, cross-platform testing, documentation, and RCs\nfor community feedback are all integrated.\n\nStep 1: Minimal Default Implementation with RC Testing\n------------------------------------------------------------------------\nDates: December 18 - January 5\nDevelopment: Implement the core feature to share only the OS name,\nwith an option to disable data sharing.\nTesting: Conduct cross-platform testing, especially on Windows.\nDocumentation: Document default behavior and configuration options.\nRelease Candidate: Submit an RC patch for community review and\nincorporate any feedback.\n\nStep 2: Verbose Mode with RC Testing\n----------------------------------------------------\nDates: January 6 - January 26\nDevelopment: Add a verbose mode, allowing detailed OS info (e.g.,\nuname -srvm on Linux).\nTesting: Run cross-platform testing to ensure verbose mode stability.\nDocumentation: Update documentation to cover verbose mode options and\nconfigurations.\nRelease Candidate: Release an RC patch for verbose mode, collect\nfeedback, and address issues as necessary.\n\nStep 3: Custom Mode with RC Testing\n---------------------------------------------------\nDates: January 27 - February 16\nDevelopment: Implement a custom mode, enabling users to tailor OS data\npreferences.\nTesting: Execute extensive cross-platform testing to verify all modes.\nDocumentation: Finalize documentation to explain custom mode setup and usage.\nRelease Candidate: Share an RC patch for custom mode with the\ncommunity, and make refinements based on feedback.\n\nLast Review and Feedback Integration\n==============================\nDates: February 17 - March 6\nAddress any last revisions based on cumulative community and\nmaintainer feedback for each feature.\nConduct a thorough review of the code, documentation, and tests to\nconfirm readiness.\nPrepare the finalized feature set for integration into Git’s mainline,\nensuring alignment with Git community expectations and protocols.\n\n\nAvailability\n========\nI will be available to work for the required minimum of 40hours per week\nduring the internship period and will be happy to extend if required.\n\nBlogging\n=======\nI also plan to keep writing blogs after two weeks, to track my\nprogress,  give updates about what I am currently working on and also\nas a documentation for future contributors.\n\nPost Outreachy Internship\n====================\nOne of my dreams is to be an active member of an open-source community\nwhich I can proudly support and contribute to. Continuing my\ncontributions after the internship is a big part of making that dream\na reality. I’m committed to contributing to Git long-term, helping to\nimprove the project and supporting new contributors along the way.\n\nAppreciation\n==========\nI really appreciate the support and guidance I got from the Git\ncommunity. I also appreciate all the effort from the outreachy mentor.\nThanks for your time.\n\nThank you.\n\nUsman Akinyemi.\n"}]}