My GSoC23 journey, which I introduced in a previous post, is almost over. It really doesn’t feel like 16 weeks have passed, but I can say that, in this period, I have learned a lot and grown as a developer.

My GSoC23 project (which I talked about in a previous post) is about implementing a feature in kw that serves as a hub for the public mailing lists archived on https://lore.kernel.org, with a focus on patch-reviewing. The feature is called kw patch-hub and I will talk about what are the lore archives and its API in a later post, but in this post, I’m going to describe the Finite-State Machine model used on this feature.

Around May, I had the opportunity of helping to introduce a Database Management System (DBMS) to a project that used a file-based database. The DBMS was SQLite3 and the project was kw. This post describes my experience.

Being a somewhat new user of Zsh - made the transition from Bash around 2 months ago - I never thought I would have to learn about its completion system or how to write my own custom completion functions so soon.

I usually have my dev system and a test machine to validate my changes for developing to the Linux kernel. I also keep my config files and use them every time for my test systems. Nevertheless, I recently had to get a different test system (but very similar), and I created a new config file based on the ones that I already had; everything worked as usual, except for this error during the boot:

Since January, I have been refactoring and improving the deploy code in order to make it easy to add other platforms. Introducing Raspberry Pi support was a great study case to find the weak points in the deploy and make it more generic. As a result, I finally have a PR that enables Raspberry PI deploy and modularizes the deploy code. Check it at:

When I started contributing to Linux Kernel, one of my favorite tasks for learning more about the kernel was following the public mailing list of the subsystem that I was interested in. A few months after I started contributing to the kernel, I became a maintainer and had to follow patches related to the driver that I was maintaining. A few weeks ago, I also became one of the maintainers of the display component under the amdgpu driver. Yeah… I am aware that I’m doing poor work as a maintainer, which I blame the lack of structure in my review flow. Don’t get me wrong, I was trying… for example, I set up my neomutt to help me with that, but unfortunately, I could not use it anymore due to external forces, which broke my already inefficient review process. Anyway, I’m uncomfortable about that since I want to be a better maintainer, but I realize that I need to fix my workflow.

For a long time, I’m aiming to expand kw to provide good support for non-x86 machines. As part of this effort, I enabled kw deploy to work with an ARM target system that resembles x86, and fortunately, it works really well. However, as a DIY enthusiast, I always wanted to enable kw to deploy custom kernels to Raspberry pi, but I had the following obstacles:

For a long time, I have been considering creating a blog for the kworflow project where we can have posts that are not suitable to the standard documentation. I had this desire because sometimes, when I was working on some issues, I took some time to appraise some exciting topics related to Bash or Linux kernel that was worth publicly sharing. However, I utterly want something informal and with a low overhead to maintain. After asses my options, I decided to use a straightforward Jekyll template with trivial automation associated with the main branch.