On Thu, Oct 19, 2023 at 11:26 AM Isoken Ibizugbe <isokenjune@xxxxxxxxx> wrote: > > Dear Git Community and Mentors, > > I hope you're doing well. I'm excited to share my application draft > for the Outreachy program with the Git project. Your feedback is > invaluable, and I'm eager to align the project with the community's > needs. Please review the attached draft and share your insights. Thanks for your project application! [...] > Why am I interested in working with the Git chosen project? > > Git has been a cornerstone for software development, enabling > developers worldwide to collaborate, innovate, and create exceptional > software. I would say without Git, my journey to pursuing my software > engineering career would be impossible, as I use it almost every day. > Yet, in this constantly evolving landscape, there is always room for > improvement, even in a well-established project. The Git project > currently relies on end-to-end tests, and this is where I see an > opportunity to make a profound impact. Being able to test libraries in > isolation via unit tests or mocks speeds up determining the root cause > of bugs. I am deeply passionate about contributing to this project and > firmly believe in the power of open-source software and the collective > intelligence of the community. A successful completion of this project > will significantly improve Git's testing capabilities and bring the > benefits of fewer errors, faster work and better testing for all > parts. Ok. [...] > Contributions to Git > > I have actively participated in Git's mailing list discussions and > contributed to a micro-project; > > - builtin/branch.c: Adjust error messages such as die(), error(), and > warning() messages used in branch, to conform to coding guidelines > (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@xxxxxxxxx/) > - Implemented changes to fix broken tests based on reviews from the > community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@xxxxxxxxx/) > - In review. Nice! > Project Goals: > > - Improve Testing Efficiency: Transitioning from end-to-end tests to > unit tests will enable more efficient testing of error conditions. > - Codebase Stability: Unit tests enhance code stability and facilitate > easier debugging through isolation. > - Simplify Testing: Writing unit tests in pure C simplifies test > setup, data passing, and reduces testing runtime by eliminating > separate processes for each test. Ok. > Project Milestones: > > - Add useful tests of library-like code > - Integrate with stdlib work Not sure what you call "stdlib" here. > - Run alongside regular make test target > > Project Timeline: > > 1. Oct 2 - Nov 20: Community Bonding > > - Understanding the structure of Git > - Getting familiar with the code I think some of this time is also spent on working on a microproject, writing an application and perhaps doing other things that regular Git developers do. > 2. Dec 4 - Jan 15: Add useful tests of library-like code > > - Identify and document the current state of the tests in the Git > t/helper directory. It would be nice if you could already take a look at that and tell us about it in your application. There are different things in t/helper. Some are worth porting and others are not. You might not want (or have time to) to classify everything right now, but if you can identify a few of each kind, and use those, or just one of them, as an example, that would be great. > - Confirm the licensing and compatibility requirements for the chosen > unit testing framework. I think those who have been working on the unit test framework have already done this. > - Develop unit tests for these library-like components. Not sure what are "these library-like components". An example would perhaps help. > - Execute the tests and ensure they cover various scenarios, including > error conditions. > - Run the tests and address any initial issues or bugs to ensure they > work as intended. Ok. > - Document the new tests and their coverage. What kind of documentation would that be? > - Seek feedback and support from mentors and the Git community > > 3. Jan 15 - Feb 15: Integrate with Stdlib Work > > - Collaborate with the team working on standard library integration. Not sure what "standard library". Actually, maybe you are talking about the goal of having a "standard library" implementation for Git which is described in this report from the Virtual Contributor's Summit: https://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/ It's true that the unit test framework would help with that goal. So yeah maybe you will have to collaborate with the team working on that goal. I am not sure at what step the work on this library will be when the internship will start though. > - Ensure that the tests for library-like code align with stdlib work. > - Verify that the tests effectively check the compatibility and > interaction of the code with standard libraries. > - Gather feedback and insights from the Git community on the > integrated tests, addressing any concerns or suggestions. Ok, but I think it would be more interesting to follow the steps with an example test. > 4. Feb 15 - March 1: Run Alongside Regular 'make test' Target and finalize > > - Configure the testing framework to run alongside the regular 'make > test' target. I think others will likely take care of that sooner. > - Ensure that the new tests are included in the standard testing suite. > - Execute 'make test' with the new tests and verify that they pass successfully. > - Document the integration process and how the new tests are included > in the standard testing procedure. > - Perform comprehensive testing of the entire unit testing framework. > - Ensure all migrated tests are working correctly within the new framework. > - Document the entire process of migrating Git's tests > - Prepare a final project report Ok, but here also following an example test would be more interesting. > Technical Requirements > > According to the documentation on the unit test project > (https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc), > the suggested best framework for the Git project is the "Custom TAP > framework" (Phillip Wood's TAP implementation), as it aligns with > Git's licensing requirements, is vendorable, and can be customized by > Git's developers as needed, but it may require some additional > development work for features like parallel execution and mock > support, but it offers a strong foundation for unit testing within the > Git project. Yeah, right. Thanks for summarizing that document! > Relevant Projects > > Simple shell - A project based on emulating a shell. It was a > collaborative project which we managed using Git. > (https://github.com/Junie06/simple_shell). > This project was written in C, which allowed me to apply my C language > knowledge, essential for Git projects. > I'm proficient in using Shell for scripting, redirections, and > permissions, as shown in my work > (https://github.com/Junie06/alx-system_engineering-devops). > Creating the simple shell project deepened my understanding of how > shells work, and I even attempted to replicate a shell environment. > Collaborating on the Simple Shell project reinforced my Git skills. Ok, nice! Best, Christian.
