{"thread":{"id":"62412","subject":"Re: [Outreachy] Final Application Timeline","startedAt":"2024-10-27T10:51:52Z","lastAt":"2024-10-28T06:06:19Z","messageCount":3,"participants":["Patrick Steinhardt","Seyi Chamber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"506145","messageId":"Zx4bEOGr8Hy-ZfX2@pks.im","threadId":"62412","inReplyTo":"CAGedMteoVFfZy1jtHMPJvByzfq9unomcA7qkCNKx9R6_ZQ6=Cw@mail.gmail.com","subject":"Re: [Outreachy] Final Application Timeline","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-27T10:50:59Z","receivedAt":"2024-10-27T10:51:52Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sat, Oct 26, 2024 at 03:50:11PM +0100, Seyi Chamber wrote:\n> Dear Mentors,\n\nHi,\n\n> It's almost the deadline to create a final application for the Git\n> community, it's a little unclear how I should create a timeline for the\n> project *Convert unit tests to use the clar testing framework*.\n\nyou may have a look at the recent thread in [1] to get some more input\non that.\n\n> Does a timeline of the first 8 weeks spent working on converting the unit\n> test framework to use the clar framework and the remaining 4 weeks\n> spent on *implementing\n> additional asserting functions for Git-specific types *and using *clar\n> upstream to improve shortcomings discovered during the integration of Git\n> with the clar* tasks sound good?\n\nWhat I'd specifically like to see is how exactly you want to work on\nthings. So it's not only \"I will convert X\", but a couple more items:\n\n  - Are there things you need to learn? When do you plan to get familiar\n    with the codebase and how do you tackle that problem?\n\n  - How do you plan to approach the topic? Do you want to convert\n    everything in one go and then send over a huge topic or rather want\n    to work on it incrementally? You can also take as inspiration the\n    last GSoC students that converted our unit tests from the test\n    helpers to our own unit testing framework.\n\n  - Do you plan to work with clar upstream in case you feel like there\n    are missing features? It might make sense to have a look at it early\n    in the cycle so that you know what to expect and what you may want\n    to implement there.\n\n  - Plan sufficient time for review cycles. The Git project is not\n    exactly the fastest-moving project, so you need to plan time\n    accordingly.\n\nOverall I don't expect a hugely detailed plan that knows ahead of time\nhow long you'll work on each of these items. I just want to see whether\nyou've got an idea for how to approach the project and how to work with\nthe Git community.\n\nLet me know in case you've got further questions!\n\nPatrick\n\n[1]: https://lore.kernel.org/git/CAPSxiM-kf8U=vzp5MoD3tUuOtnNjcCgPhLdriyeQo5CGf=EhyQ@mail.gmail.com/\n"},{"id":"506169","messageId":"CAGedMtfrM1NZ6SY3SEy3+zSSvbB+D+Z_03jo9235fXoyuVXW5w@mail.gmail.com","threadId":"62412","inReplyTo":"Zx4bEOGr8Hy-ZfX2@pks.im","subject":"Re: [Outreachy] Final Application Timeline","fromName":"Seyi Chamber","fromEmail":"kuforiji98@gmail.com","sentAt":"2024-10-27T23:17:21Z","receivedAt":"2024-10-27T23:17:34Z","isPatch":false,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"On Sun, 27 Oct 2024 at 11:51, Patrick Steinhardt <ps@pks.im> wrote:\n>\n> On Sat, Oct 26, 2024 at 03:50:11PM +0100, Seyi Chamber wrote:\n> > Dear Mentors,\n>\n> Hi,\n>\n> > It's almost the deadline to create a final application for the Git\n> > community, it's a little unclear how I should create a timeline for the\n> > project *Convert unit tests to use the clar testing framework*.\n>\n> you may have a look at the recent thread in [1] to get some more input\n> on that.\n>\n> > Does a timeline of the first 8 weeks spent working on converting the unit\n> > test framework to use the clar framework and the remaining 4 weeks\n> > spent on *implementing\n> > additional asserting functions for Git-specific types *and using *clar\n> > upstream to improve shortcomings discovered during the integration of Git\n> > with the clar* tasks sound good?\n>\n> What I'd specifically like to see is how exactly you want to work on\n> things. So it's not only \"I will convert X\", but a couple more items:\n>\n>   - Are there things you need to learn? When do you plan to get familiar\n>     with the codebase and how do you tackle that problem?\n>\n>   - How do you plan to approach the topic? Do you want to convert\n>     everything in one go and then send over a huge topic or rather want\n>     to work on it incrementally? You can also take as inspiration the\n>     last GSoC students that converted our unit tests from the test\n>     helpers to our own unit testing framework.\n>\n>   - Do you plan to work with clar upstream in case you feel like there\n>     are missing features? It might make sense to have a look at it early\n>     in the cycle so that you know what to expect and what you may want\n>     to implement there.\n>\n>   - Plan sufficient time for review cycles. The Git project is not\n>     exactly the fastest-moving project, so you need to plan time\n>     accordingly.\n>\n> Overall I don't expect a hugely detailed plan that knows ahead of time\n> how long you'll work on each of these items. I just want to see whether\n> you've got an idea for how to approach the project and how to work with\n> the Git community.\n>\n> Let me know in case you've got further questions!\n>\n> Patrick\n>\n> [1]: https://lore.kernel.org/git/CAPSxiM-kf8U=vzp5MoD3tUuOtnNjcCgPhLdriyeQo5CGf=EhyQ@mail.gmail.com/\n\nDear Community,\n\nI hope you are doing well. My name is Seyi Kuforiji, and I’m thrilled\nto connect with you regarding my interest in contributing to the Git\nproject as part of the upcoming internship. With a background in\nSoftware Engineering and hands-on experience in C Programming, Git,\nPython, and other tools, I’m excited to use my skills to contribute\nmeaningfully to the Git community.\n\n\n## A Bit About My Background\n\nMy journey into software development began with Python, which\nintroduced me to programming concepts in a beginner-friendly manner\n(one of Python's biggest strengths :) ) and eventually led me to\nexplore version control with Git. A few years later, I pursued and\nobtained a software engineering certification, building a solid\nfoundation in programming with C as my base language before\nprogressing to tools like Python and JavaScript.\n\nOver the years, I’ve worked with various tools and on a variety of\nprojects, from a simple shell program that displays a prompt, accepts\nsingle-word commands, and executes each one, handling errors and\nexiting gracefully on EOF (Ctrl+D) [Simple\nShell](https://github.com/Seyi007/simple_shell), to full-fledged web\napplications where I collaborated with people from diverse\nbackgrounds.\n\nAlong the way, I’ve gained experience writing unit tests in different\nlanguages, reinforcing my ability to learn quickly and solve complex\nproblems—a skill that has been invaluable in my development journey.\n\n## Project objective and scope\n\nThe primary objective of this project is to transition Git's existing\nunit tests from a homegrown testing framework (such as\nt/unit-tests/test-lib.h) to the Clar testing framework. Using Clar\naims to improve the readability, consistency, and maintainability of\nGit’s unit tests.\n\nThe existing structure of Git’s unit tests consists mainly of .c files\nwithin t/unit-tests/, leveraging custom frameworks and assertions.\nClar, with its organized and efficient testing model, is well-suited\nto replace these frameworks and streamline Git’s approach to unit\ntesting.\n\nAs displayed in this patch:\nhttps://lore.kernel.org/git/604303e31aad3a9e74f7bdddc84f11d4d137c864.1725459142.git.ps@pks.im/\n\nThe following improvements can be observed\n\n* Clar’s test structure provides more organized, descriptive test\nfunctions, such as test_strvec__push or test_strvec__clear. Each\nfunction isolates a specific test scenario, enhancing readability and\nmaintainability.\n\n* Clar’s macros, such as cl_assert and cl_assert_equal_*, provide\nuniform assertion syntax, making tests easier to understand and\nmaintain. The check_* functions from the previous framework were\ncustom, adding complexity, while Clar's built-in assertions improve\nstandardization.\n\n* Using Clar aligns Git’s unit tests with a more structured framework,\nfacilitating integration across the project. It potentially simplifies\ncontributions, as developers familiar with Clar can readily understand\nand add tests.\n\n* Clar includes built-in support for more complex test setups and\ntear-down functions, making it easier to expand testing scenarios if\nnew strvec features are introduced.\n\n* By adopting Clar, there’s an opportunity to identify and address any\nframework limitations through upstream contributions, potentially\nimproving Clar itself and benefiting future Git projects.\n\n\n## Contributions\n\nI modernized a few test scripts during the contribution phase by\nremoving whitespaces after the redirect operator. Please find the\nstatus of my contributions below:\n\n- [PATCH v2 Outreachy] t7011: ensure no whitespace after redirect\n\n\n    link: https://lore.kernel.org/git/20241019163439.274656-1-kuforiji98@gmail.com/\n\n\n    Status: Merged\n\n\n\n    Description: This change updates the script to conform to the coding\n    standards outlined in the Git project's documentation. According to the\n    guidelines in Documentation/CodingGuidelines under \"Redirection\n    operators\", there should be no whitespace after redirection operators.\n\n\n\n- [PATCH Outreachy] t9101: ensure no whitespace after redirect\n\n    link: https://lore.kernel.org/git/20241023121113.915310-1-kuforiji98@gmail.com/\n\n\n    Status: Queued\n\n\n    Description: This change updates the script to conform to the coding\n    standards outlined in the Git project's documentation. According to the\n    guidelines in Documentation/CodingGuidelines under \"Redirection\n    operators\", there should be no whitespace after redirection operators.\n\n\n\n## Project steps\n\n-  Initial Preparation and Codebase Familiarization\n-  Develop a structured approach to incremental conversion of tests.\n-  Initial Conversions and Incremental Submission\n-  Feedback and Clar Collaboration\n-  Continued Conversions and Feature Integration\n-  Final Documentation and Wrap-Up\n\n### Details\n\nWeek 1-2: Initial Preparation and Codebase Familiarization\n- Objective: Get familiar with the Git codebase, particularly with\ntest structures, existing frameworks, and Clar.\n- Tasks:\n  - Review the Git project's code style and standards documentation.\n  - Study the layout of unit tests, focusing on the t/unit-tests and\nt/helper directories.\n  - Analyze previous GSoC students’ work on test conversions for context.\n  - Review the Clar framework’s documentation and identify any\npotential features to implement or adapt.\n- Milestone: Build a foundational understanding of the Git codebase\nand the test framework, and outline any necessary feature\nimplementations in Clar.\n\n---\n\nWeek 3-4: Strategic Conversion Planning\n- Objective: Develop a structured approach to incremental conversion of tests.\n- Tasks:\n  - Identify an initial set of unit tests for conversion to the Clar framework.\n  - Create a conversion roadmap, prioritizing simpler tests for early\nconversions.\n  - Documenting conversions (notes, comments, dedicated documentation).\n  - Confirm the feasibility of incremental patch submissions based on\nthe Git community’s preferences.\n- Milestone: Establish a conversion plan that balances incremental\nwork with periodic review cycles.\n\n---\n\nWeek 5-7: Initial Conversions and Incremental Submission\n- Objective: Begin test conversions and submit initial patches for\ncommunity review.\n- Tasks:\n  - Convert the first batch of unit tests according to the planned roadmap.\n  - Ensure compliance with Git’s coding standards and best practices\nfor each conversion.\n  - Submit the first set of patches for review, incorporating any\ninitial feedback.\n  - Document any challenges encountered during the conversions.\n- Milestone: Complete and submit the first set of converted unit\ntests, gather feedback, and adjust the approach as needed.\n\n---\n\nWeek 8-9: Feedback and Clar Collaboration\n- Objective: Address reviewer feedback and explore collaboration with\nClar upstream.\n- Tasks:\n  - Apply reviewer feedback to improve both past and upcoming conversions.\n  - Contact Clar upstream if any identified features or improvements\nare feasible and valuable.\n  - Begin implementing any features in Clar that could aid in Git’s\nunit test migration, if needed.\n- Milestone: Develop a collaborative approach with Clar upstream,\nensuring feedback-driven improvement in conversions.\n\n---\n\nWeek 10-11: Continued Conversions and Feature Integration\n- Objective: Maintain momentum in conversions and integrate Clar\nfeatures if implemented.\n- Tasks:\n  - Continue converting tests based on the roadmap, focusing on\nhigher-priority or more complex unit tests.\n  - Apply any newly implemented features in Clar to simplify or\nenhance conversions.\n  - Share ongoing work with mentors or peers for mid-cycle feedback.\n  - Begin planning final documentation for conversions and processes.\n- Milestone: Have a significant portion of unit tests converted with\nany Clar-based improvements integrated.\n\n---\n\nWeek 12: Final Documentation and Wrap-Up\n- Objective: Finalize the project, prepare for final reviews, and\nsummarize work.\n- Tasks:\n  - Complete final documentation detailing the conversion process, any\nissues addressed, and feedback on Clar.\n  - Prepare a presentation or report summarizing key takeaways,\nincluding potential future work.\n  - Submit final patches and documentation to the Git community.\n- Milestone: Wrap up the project with comprehensive documentation and\nprepare for potential post-internship contributions.\n\n\n## Availabilility\n\nI am available for the duration of my internship for a total of 30\nhours per week. I do not have any school activities or work\ncommitments during this period, allowing me to fully dedicate my time\nand effort to the internship.\n\n## Final Remark\n\nI would like to express my deepest gratitude to everyone who has\nguided and supported me throughout my contribution phase. Your\nencouragement, insights, and patience have made a significant impact\non my journey. Each interaction has not only enhanced my understanding\nof the project but has also inspired me to push my boundaries and\nstrive for excellence.\n\nThank you for sharing your knowledge, offering constructive feedback,\nand being a constant source of motivation. I am truly fortunate to\nhave had such remarkable mentors and colleagues by my side during this\nphase. Your dedication to fostering a collaborative and supportive\nenvironment has made all the difference, and I look forward to\ncontinuing this journey together, and hopefully becoming a mentor to\nfuture applicants\n\n\nThanks\n\nSeyi\n"},{"id":"506199","messageId":"Zx8pzrgsI-S_LbzQ@pks.im","threadId":"62412","inReplyTo":"CAGedMtfrM1NZ6SY3SEy3+zSSvbB+D+Z_03jo9235fXoyuVXW5w@mail.gmail.com","subject":"Re: [Outreachy] Final Application Timeline","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-28T06:06:12Z","receivedAt":"2024-10-28T06:06:19Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Oct 28, 2024 at 12:17:21AM +0100, Seyi Chamber wrote:\n> \n> Dear Community,\n> \n> I hope you are doing well. My name is Seyi Kuforiji, and I’m thrilled\n> to connect with you regarding my interest in contributing to the Git\n> project as part of the upcoming internship. With a background in\n> Software Engineering and hands-on experience in C Programming, Git,\n> Python, and other tools, I’m excited to use my skills to contribute\n> meaningfully to the Git community.\n\nThanks for your application! I don't really have anything to add, so\nplease don't forget to also upload it to Outreachy in case you haven't\nalready done so.\n\nPatrick\n"}]}