Posted on June 25, 2024 by Felipe Aníbal
Last updated on June 25, 2024
We started the semester working on the linux kernel. This was by far the project with the greatest learning curve. Before contributing we spent a few weeks understanding how the kernel was structured with its many subsystems, learning about a complex contribution workflow (with different trees and cycles) and setting up the environment with virtual machines to build and deploy the kernel. Once we made our patch we still had to learn how to send the patch to the correct maintainers and how to check for updates and replies. It was a lot to learn, but it was definetly worth it. Once we sent a contribution to the kernel, every other project seemed more tangible. It gave us confidence to take on other projects afterwards.
Our patch implemented a correction in the representation of negative numbers in the driver ltc2309. The driver was not correctly using the 2's complent form for binary numbers, so we corrected that. However we realized that although the driver's reference sheet mentioned negative numbers, the part of the driver that used them (called bipolar mode) was not implemented. In order to fix that we would have to write from scratch a new operating mode for the driver. That was beyond our knowledge and would take us a lot of time, so we mentioned the problem in the lore, but decided not to work on that.
As a second project we decided to work on KW, a project to help reduce the overhead when contributing to the kernel. We looked through the issues and decided to work on improving the display of a function in the drm module. The contribution process for this project was a lot easier. Instead of sending a patch through email, we forked the project on github, made the necessary changes and sent a pull-request. After receiving feedback from the maintainers, we updated the PR a few times and our contribution was merged!
After contributing to KW we participated in a workshop about Debian Packaging with Debian developer Joênio Marques. We learned how to make and maintain Debian packages and followed his tutorial to make a dummy package. As an exercise we tried to make another package and this time officially send it upstream. Unfortunately the package we chose had many dependencies that were also not packaged, so the project grew bigger than we expected and we had to drop it as it was out of the scope of the discipline.
For the final project we decided to work on a software that we use daily. We decided to contribute to gnome. We looked through the sub-projects inside of gnome and through the open issues in each project and decided to work on the gnome-calendar. We were truly amazed with gnome's contribution workflow. It was by far the one with the least overhead. Gnome offers a builder that works as an IDE and allows us to edit the code and test it immediatly with no need for virtual machines or containers. It made the process easy and allowed us to focus on understanding the code and engineering our contributions.
First we chose a newcomers issue which was great to get more used to the code structure. We have sent a merge request, and we're waiting for a feedback. Meanwhile we chose a second and more challengin issue and made a suggestion that might fix it, but we're waiting for a confirmation before writing the code.
Overall the discipline was great! We had the chance to work real-world large projects that are used daily by thousands of people worldwide. We gained confidence to work on open source projects, to understand and propose changes to large software and we practiced the use of day-today tools like git, github and gitlab. We also saw firsthand the importance of clean code, good documentation, tests and an active community, to the long term maintenance of code and to the cooperation of multiple people on the same project. I hope to contribute to more open source software after this discipline.