* Re: [Outreachy] Final Application Timeline
2024-10-27 10:50 ` [Outreachy] Final Application Timeline Patrick Steinhardt
@ 2024-10-27 23:17 ` Seyi Chamber
2024-10-28 6:06 ` Patrick Steinhardt
0 siblings, 1 reply; 3+ messages in thread
From: Seyi Chamber @ 2024-10-27 23:17 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Phillip Wood, Kristoffer Haugsbakk, Taylor Blau
On Sun, 27 Oct 2024 at 11:51, Patrick Steinhardt <ps@pks.im> 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@mail.gmail.com/
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@pks.im/
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@gmail.com/
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@gmail.com/
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
^ permalink raw reply [flat|nested] 3+ messages in thread