Hi team, I would like to have reviews on my Google Docs link:https://docs.google.com/document/d/1Kdx8DVWF3c5pwV5-A8Z4n-SoRHlMDncI1gNeGCiLNsE/edit?usp=sharing Name:Nsengiyumva Wilberforce Major:Software engineering Mobile no.:+256 785065399 Email:nsengiyumvawilberforce@xxxxxxxxx IRC:wilber4c Github:nsengiyumva-wilberforce Linkedin:https://www.linkedin.com/in/nsengiyumva-wilberforce-623664192/ Time Zone:EAT (UTC + 03:00) About me I am doing a Bachelor of Science in software engineering at Makerere university in my 4th year(final). I spend most of my time writing PHP applications. I am also interested in Java and embedded systems development and I have participated in embedded systems development projects like AdEMNEA. Microproject When I was browsing the outreachy projects on outreachy website, I was super excited about Git because I use it in most of my college work. At first, it was intimidating for me to introduce myself to the community. But I am glad I took a step. I am glad that I completed my microproject and the whole process gave me confidence on how to submit patches, communicate with the community members and interestingly, it was a big learning process for me. The following are the details about my microproject with public-inbox links to different versions. Mailing List for the microproject: https://lore.kernel.org/git/pull.1362.v4.git.git.1665772130030.gitgitgadget@xxxxxxxxx/ Github: https://github.com/git/git/pull/1362 Status: next Proposed Project Abstract Git has an old problem of duplicated implementations of some logic. For example, Git had at least 4 different implementations to format command output for different commands. The foremost aim of this project is to simplify codebase by getting rid of duplication of a similar logic and, as a result, simplify adding new functionality. The current task is to reuse ref-filter formatting logic to minimize code duplication and to have one unified interface to extract all needed data from the object and to print it properly. Previous Work Hariom Verma contributed(final report) tremendously towards “Unifying Git’s format languages” during his 2020 GSoC internship. Hariom finished most of the formatting options and this will help me build on his work. His work looks smart and understandable thus adding on his work will be easy. And also his blog is very fabulous, it’s a shooting point for me to start understanding the codebase very well. Hariom mentions in his report that 30 % of the log related tests are failing, he also mentions that the cause of tests failure is because of the missing mailmap logic and mbox/email commit format. Hariom also says it does not handle unknown formatting options. I plan to start with his advice about the cause of the failure of these tests and then intuitively refactor them into something cool. Summary of remaining tasks by Hariom -Around 30% log related tests are failing -Teach pretty-lib.{c,h} to handle incorrect formatting option -Email/MBoxed commit format needs work Some useful mailing lists links from Hariom Improvements to ref-filter Fix trailers atom bugs and improved tests Unify trailer logic for pretty.{c,h} and ref-filter.{c, h} Olga<olyatelezhnaya@xxxxxxxxx> has done great work in “Unifying Git’s format languages” during Outreachy Round 15 and continued even after that [from 28-09-2017 to 04-04-2019]. Her work is mostly related to `cat-file` and `ref-filter`. She already did a pretty nice job in preparing ref-filter for more general usage of its formatting logic. It will give me the possibility to make the migration of pretty.c easier. The Plan My task is to look at how pretty formats are different from ref-filter formats. When some format is supported by the pretty formats but not by the ref-filter formats, and should prepare some patches to support the ref-filter format. I will basically build on Hariom’s previous work Step 1:List down all the formats supported by the pretty format but are not supported by the ref-filter format Step 2:Read through different patches related pretty and ref-filter formats submitted by different contributors to get a solid and a thorough understanding of the pretty and ref-filter formats. Step 3:Understanding an implementation of one or two pretty formats, and then look at how it was implemented in ref-filter format. This is going to give me direction to refactor the remaining pretty formats Step 4(possible approach): Pick one format option at a time and convert it to use ref-filter option format Estimated Timeline Time Period period: December 5,2022 - January 2, 2023 Community bonding tasks -understanding all the logic of pretty.* and ref-filter.* (what functions are used and how all formatting process is going) -Working with mentors and identifying the best candidates to be converted first. -Converting a couple of formatting options to reuse ref-filter formatting logic. -Update Documentation. period: December 25, 2022 Christmas celebrations: Join my parents for celebrations period: January 1, 2023: New year’s day holiday:Join my parents for celebrations period: January 3 - February 3, 2023 Coding Phase 1 tasks -Add on Hariom’s work:Converting more formatting options to reuse ref-filter formatting logic. -Finish his incomplete work -Update Documentation. -Possibly look at Olga’s work period: January 18, 2023: Cake cutting with my friends My Birthday:cake cutting period:From January 6 - January 18, 2023: Semester Exams: I will be working for a few hours per day and always be available to reply to any communication period:February 3 - March 3, 2023 Coding Phase 2 tasks -Final touch-ups and bug fixes(if any) -Update Documentation -Wrapping up. Blogging about Git I do love writing a lot however much I have not taken time to put out my personal opinions and thinking. Being an avid reader, I think it’s now my time to start letting other people read what I write, to let people know what I think, what I am doing with my life. And guess what, I am super excited to start with Git. Availability I can easily devote 50 hours per week since my college just requires 15 hours per week. I plan even to work more extra hours for my internship tasks when time allows. Post Outreachy Apart from being an Outreachy intern, I plan to remain a member of git community even after my internship, because I believe there is more today even after the Outreachy internship Here are some other things I’d like to do beyond Outreachy Mentor other students Doing code reviews for other contributors May be complete the work that I will have left pending after my internship Keep learning from all of you... Experience with Open Source I have little experience with open source, so I hope to learn a lot through my internship with Git from you all. Motivation Git being a world’s best developer version control system, I feel overjoyed that even my little first patch was accepted. The community is very welcoming, the people there answer questions very first and this turns everything overwhelming to a simple process Closing remarks (Optional) I am a consistent and passionate learner. Even if solving a problem may look tricky to me, I just give it all my 100% time and think of 1000s of ways to approach it. I know I do not have the required expertise to begin working with a skilled team like Git but I believe in learning slowly by slowly until I will make it to the peak. I hope you consider and give me a chance to work with git. It’s a great hope I have that this opportunity is bringing me closer to my dreams. Thanks for your consideration. Best Regards Nsengiyumva wilberforce
