Today I contributed to the project Kernel Workflow, which is a software that helps the user to contribute to the Linux Kernel, reducing the steps to make it easier for anyone who has an interest in helping the Tux community.
First step
The first part of the contribution was to search for some interesting issues in the repository. There are many issues marked as “good first issues”, which are nice for starters, like me. The one that caught my attention is a new functionality to the pomodoro function in the KW.
The pomodoro function
This function in kw is made for people who want to join the pomodoro study mode, which includes some limited time to develop a task in the Kernel. It sets an alarm based on your time. The problem is that Pomodoro has an extensive list of arguments, that describe the time and task. So, you need to rewrite the arguments all over again to restart the pomodoro.
The issue
This is issue is made to add a new command to pomodoro: the --repeat-previous flag, which repeats the exact last command used in pomodoro.
Idea behind the issue
KW is executed in different processes each time you execute the command. Each command executed is stored in a local Database, that is used to check for last commands and for tests verification. In this way, we can use this Database for our command, we just have to query the newest pomodoro command and repeat it.
Kworkflow has a more restricted group of maintenors, so it is important to follow all the recommendations and reviews requested by a maintenor. In my case, Rodrigo Siqueira and David Tadokoro followed my PR since the beginning.
First attempt
Tests
In addition to the enhancement, some tests were added for the functions involved in the --repeat-previous flag. Simple tests were made, just to make sure the function is returning the right values for the right inputs, and vice-versa.
First Idea
My first idea was to use a temporary file to store the last command used by the user and repeat it properly. I did a Pull Request using this idea, which failed in basically all the tests. Because I didn’t know how to modify a Pull Request, I just closed it, fixed it, and opened another one. After talking with David Tadokoro and studying more about the kw implementation, I learned that kw has a local database, that stores all commands executed by the user. This was perfect for the development of my function, instead of creating a temporary file.
Second Idea
Using the database and recommendations given by David, we reached a good commit, with lots of new coding and implementations. For example, we completed the kw documentation and auto-completion for the new repeat-previous command. After this, we implemented the function by itself, which showed the user the pomodoro session about to be repeated and asks the user if he really wanted to repeat it. This is a much more user-friendly approach than before.
Besides this, is important to implement tests. It was very hard to produce good and diversified tests. But using some help from Rodrigo Siqueira, a kw maintainer, that recommended adding some extra sessions (add = insert in the local database) between tests to check if the correct one is really being selected.
Pull Request
In my first PR to the unstable branch in Kernel Workflow, I didn’t make it because my syntax wasn’t accorded with the rest of the program. So, after fixing this and fixing the tests that weren’t quite working well, I could do another Pull Request to the repository.
Opening a new PR wasn’t the proper way of reworking a problem pointed out by a kw maintainer in a review request. After talking with David Tadokoro (one of the kw maintainers), he taught me how to rework an old commit (the commit used by the PR), which if I update it with another commit or message, will update too in my PR. This is called force push, and it is very useful. After this, I did a dummy thing of syncing my fork (doing a git pull compared to the unstable branch in the kworkflow main repository), which added lots of new commits to my PR, breaking it. I desperately tried to delete the commits, which I did with success. But after deleting all the commits (including my one), the Pull Request closed itself.
After asking for help to David, we fixed the PR and commits, he re-opened my PR and all went well. We received some reviews from Siqueira, which we already worked on, and sent the PR again. After some review requests and fixes, we reached a good commit, that worked very well.
Conclusion
Besides being the most complicated contribution I made in my MAC0470 cycle, It was very nice to get some Git tips from the maintainers, like changing a commit, deleting it or only changing its description and message. It was very nice to contribute to such a big project like kworkflow. In general, It was a very nice (and long) experience, which I am willing to try it again in the future.
After working with some bash scripting in KW, I was able to learn a bit more about the Kernel and its associated tools, like this program. It was nice to learn about tests, checking and code formatting, in addition to test my Software Engineering skills in working with a project manager like GitHub.
Update
After some time, my PR got accepted with some changed com David, we reached a good project and a good new function for kworkflow. The commit was merged and I’ve made the contribution after some long time.