On Sun, 27 Oct 2024 at 11:51, Patrick Steinhardt <ps@xxxxxx> wrote: > > On Sat, Oct 26, 2024 at 03:50:11PM +0100, Seyi Chamber wrote: > > Dear Mentors, > > Hi, > > > It's almost the deadline to create a final application for the Git > > community, it's a little unclear how I should create a timeline for the > > project *Convert unit tests to use the clar testing framework*. > > you may have a look at the recent thread in [1] to get some more input > on that. > > > Does a timeline of the first 8 weeks spent working on converting the unit > > test framework to use the clar framework and the remaining 4 weeks > > spent on *implementing > > additional asserting functions for Git-specific types *and using *clar > > upstream to improve shortcomings discovered during the integration of Git > > with the clar* tasks sound good? > > What I'd specifically like to see is how exactly you want to work on > things. So it's not only "I will convert X", but a couple more items: > > - Are there things you need to learn? When do you plan to get familiar > with the codebase and how do you tackle that problem? > > - How do you plan to approach the topic? Do you want to convert > everything in one go and then send over a huge topic or rather want > to work on it incrementally? You can also take as inspiration the > last GSoC students that converted our unit tests from the test > helpers to our own unit testing framework. > > - Do you plan to work with clar upstream in case you feel like there > are missing features? It might make sense to have a look at it early > in the cycle so that you know what to expect and what you may want > to implement there. > > - Plan sufficient time for review cycles. The Git project is not > exactly the fastest-moving project, so you need to plan time > accordingly. > > Overall I don't expect a hugely detailed plan that knows ahead of time > how long you'll work on each of these items. I just want to see whether > you've got an idea for how to approach the project and how to work with > the Git community. > > Let me know in case you've got further questions! > > Patrick > > [1]: https://lore.kernel.org/git/CAPSxiM-kf8U=vzp5MoD3tUuOtnNjcCgPhLdriyeQo5CGf=EhyQ@xxxxxxxxxxxxxx/ Dear Community, I hope you are doing well. My name is Seyi Kuforiji, and I’m thrilled to connect with you regarding my interest in contributing to the Git project as part of the upcoming internship. With a background in Software Engineering and hands-on experience in C Programming, Git, Python, and other tools, I’m excited to use my skills to contribute meaningfully to the Git community. ## A Bit About My Background My journey into software development began with Python, which introduced me to programming concepts in a beginner-friendly manner (one of Python's biggest strengths :) ) and eventually led me to explore version control with Git. A few years later, I pursued and obtained a software engineering certification, building a solid foundation in programming with C as my base language before progressing to tools like Python and JavaScript. Over the years, I’ve worked with various tools and on a variety of projects, from a simple shell program that displays a prompt, accepts single-word commands, and executes each one, handling errors and exiting gracefully on EOF (Ctrl+D) [Simple Shell](https://github.com/Seyi007/simple_shell), to full-fledged web applications where I collaborated with people from diverse backgrounds. Along the way, I’ve gained experience writing unit tests in different languages, reinforcing my ability to learn quickly and solve complex problems—a skill that has been invaluable in my development journey. ## Project objective and scope The primary objective of this project is to transition Git's existing unit tests from a homegrown testing framework (such as t/unit-tests/test-lib.h) to the Clar testing framework. Using Clar aims to improve the readability, consistency, and maintainability of Git’s unit tests. The existing structure of Git’s unit tests consists mainly of .c files within t/unit-tests/, leveraging custom frameworks and assertions. Clar, with its organized and efficient testing model, is well-suited to replace these frameworks and streamline Git’s approach to unit testing. As displayed in this patch: https://lore.kernel.org/git/604303e31aad3a9e74f7bdddc84f11d4d137c864.1725459142.git.ps@xxxxxx/ The following improvements can be observed * Clar’s test structure provides more organized, descriptive test functions, such as test_strvec__push or test_strvec__clear. Each function isolates a specific test scenario, enhancing readability and maintainability. * Clar’s macros, such as cl_assert and cl_assert_equal_*, provide uniform assertion syntax, making tests easier to understand and maintain. The check_* functions from the previous framework were custom, adding complexity, while Clar's built-in assertions improve standardization. * Using Clar aligns Git’s unit tests with a more structured framework, facilitating integration across the project. It potentially simplifies contributions, as developers familiar with Clar can readily understand and add tests. * Clar includes built-in support for more complex test setups and tear-down functions, making it easier to expand testing scenarios if new strvec features are introduced. * By adopting Clar, there’s an opportunity to identify and address any framework limitations through upstream contributions, potentially improving Clar itself and benefiting future Git projects. ## Contributions I modernized a few test scripts during the contribution phase by removing whitespaces after the redirect operator. Please find the status of my contributions below: - [PATCH v2 Outreachy] t7011: ensure no whitespace after redirect link: https://lore.kernel.org/git/20241019163439.274656-1-kuforiji98@xxxxxxxxx/ Status: Merged Description: This change updates the script to conform to the coding standards outlined in the Git project's documentation. According to the guidelines in Documentation/CodingGuidelines under "Redirection operators", there should be no whitespace after redirection operators. - [PATCH Outreachy] t9101: ensure no whitespace after redirect link: https://lore.kernel.org/git/20241023121113.915310-1-kuforiji98@xxxxxxxxx/ Status: Queued Description: This change updates the script to conform to the coding standards outlined in the Git project's documentation. According to the guidelines in Documentation/CodingGuidelines under "Redirection operators", there should be no whitespace after redirection operators. ## Project steps - Initial Preparation and Codebase Familiarization - Develop a structured approach to incremental conversion of tests. - Initial Conversions and Incremental Submission - Feedback and Clar Collaboration - Continued Conversions and Feature Integration - Final Documentation and Wrap-Up ### Details Week 1-2: Initial Preparation and Codebase Familiarization - Objective: Get familiar with the Git codebase, particularly with test structures, existing frameworks, and Clar. - Tasks: - Review the Git project's code style and standards documentation. - Study the layout of unit tests, focusing on the t/unit-tests and t/helper directories. - Analyze previous GSoC students’ work on test conversions for context. - Review the Clar framework’s documentation and identify any potential features to implement or adapt. - Milestone: Build a foundational understanding of the Git codebase and the test framework, and outline any necessary feature implementations in Clar. --- Week 3-4: Strategic Conversion Planning - Objective: Develop a structured approach to incremental conversion of tests. - Tasks: - Identify an initial set of unit tests for conversion to the Clar framework. - Create a conversion roadmap, prioritizing simpler tests for early conversions. - Documenting conversions (notes, comments, dedicated documentation). - Confirm the feasibility of incremental patch submissions based on the Git community’s preferences. - Milestone: Establish a conversion plan that balances incremental work with periodic review cycles. --- Week 5-7: Initial Conversions and Incremental Submission - Objective: Begin test conversions and submit initial patches for community review. - Tasks: - Convert the first batch of unit tests according to the planned roadmap. - Ensure compliance with Git’s coding standards and best practices for each conversion. - Submit the first set of patches for review, incorporating any initial feedback. - Document any challenges encountered during the conversions. - Milestone: Complete and submit the first set of converted unit tests, gather feedback, and adjust the approach as needed. --- Week 8-9: Feedback and Clar Collaboration - Objective: Address reviewer feedback and explore collaboration with Clar upstream. - Tasks: - Apply reviewer feedback to improve both past and upcoming conversions. - Contact Clar upstream if any identified features or improvements are feasible and valuable. - Begin implementing any features in Clar that could aid in Git’s unit test migration, if needed. - Milestone: Develop a collaborative approach with Clar upstream, ensuring feedback-driven improvement in conversions. --- Week 10-11: Continued Conversions and Feature Integration - Objective: Maintain momentum in conversions and integrate Clar features if implemented. - Tasks: - Continue converting tests based on the roadmap, focusing on higher-priority or more complex unit tests. - Apply any newly implemented features in Clar to simplify or enhance conversions. - Share ongoing work with mentors or peers for mid-cycle feedback. - Begin planning final documentation for conversions and processes. - Milestone: Have a significant portion of unit tests converted with any Clar-based improvements integrated. --- Week 12: Final Documentation and Wrap-Up - Objective: Finalize the project, prepare for final reviews, and summarize work. - Tasks: - Complete final documentation detailing the conversion process, any issues addressed, and feedback on Clar. - Prepare a presentation or report summarizing key takeaways, including potential future work. - Submit final patches and documentation to the Git community. - Milestone: Wrap up the project with comprehensive documentation and prepare for potential post-internship contributions. ## Availabilility I am available for the duration of my internship for a total of 30 hours per week. I do not have any school activities or work commitments during this period, allowing me to fully dedicate my time and effort to the internship. ## Final Remark I would like to express my deepest gratitude to everyone who has guided and supported me throughout my contribution phase. Your encouragement, insights, and patience have made a significant impact on my journey. Each interaction has not only enhanced my understanding of the project but has also inspired me to push my boundaries and strive for excellence. Thank you for sharing your knowledge, offering constructive feedback, and being a constant source of motivation. I am truly fortunate to have had such remarkable mentors and colleagues by my side during this phase. Your dedication to fostering a collaborative and supportive environment has made all the difference, and I look forward to continuing this journey together, and hopefully becoming a mentor to future applicants Thanks Seyi
