GSoC23 Final Report

Written by David Tadokoro , published on August 26, 2023

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 proposal was to develop a feature for the kw project that served as a hub for patches in, an archive for public mailing lists related to Linux kernel.

This feature is named kw patch-hub, and this blog post is a “final report” of my GSoC23 contributions.

This first section describes my contributions to kw that are not directly related to the kw patch-hub feature but were part of my GSoC23. Nonetheless, these were important in their own context and made me more in sync with kw coding style, its contribution model, and, most importantly, with my mentors and people around the project (which I found most invaluable).

Adding Support for Native Zsh Completions

I contributed meaningful changes to kw project during the application period. My first significant contribution (both in scope and number of commits) was adding support for native Zsh completions. Without getting into too much detail, each Shell, say, Bash, can provide command completions. In other words, it’s the well-known behavior of hitting TAB and waiting for the Shell to either complete the command you are typing or show possible completions.

These completions are Shell-dependent, and kw only had native support for Bash completions. Zsh completions were adapted from the native Bash completions, but this “emulation” didn’t work and resulted in broken completions for Zsh. This was a waste, as the Zsh completion system provided deeper features than Bash, like highlighting options shown, coupling documentation with options shown, and more.

During February I worked on bringing kw support for native Zsh completions. I described this in further detail in an earlier post, but you can see the full Pull Request with 29 commits by clicking here. To illustrate, below is a demo of the results achieved.

Kw Zsh Completion

Introducing SQLite3 to kw

From before the Community Bonding Period began until halfway through it (from mid-April to mid-May), I worked on introducing the Database Management System (DBMS) SQLite3 to kw. This was a long-awaited addition for the kw community, as it would improve the project’s scalability and allow the collection of statistics.

I discussed this in further detail in an earlier post and the full Pull Request with 14 commits representing this contribution can be accessed here.

I really want to stress that I didn’t work on this contribution alone, as the whole database schema was made by Rubens Gomes Neto and Magali Lemes, and the base of the migration script and library functions was made by Rubens Gomes Neto. My work was built upon theirs and I worked on refining little details of the schema, finishing the migration script, and, mainly, integrating the database all around the project.

Throughout the year, I also contributed all around the kw project. Below is a list of every merged Pull Request concerning other work not related to my main GSoC23 project. Note that these PRs appear as Closed, but that is because the project’s maintainers clone the PR locally, commit themselves the changes, and close the PR.

Pull Request Nº of commits
tests: report_test: Fix terminal and file outputs from test_save_data_to() 1
Allow some kw deploy commands to be run outside kernel tree 4
documentation: man: kw: Revise deploy subsection 1
src: kw_remote: Fix not failing when missing valid options 1
src: kw_remote: Fix remove remote that is prefix of other remote 1
Revise kw remote man page 2
documentation: dependencies: Add curl and xpath dependencies 1
src: lib: remote: Fix ssh connection fail message with remote.config 1

kw patch-hub

My project focus was to add a feature to kw that was a terminal-based User Interface to the archives with patch-reviewing in mind. In my proposal, I listed the following deliverables for kw patch-hub:

  1. A user-friendly interface to patchsets in the lore archives.
  2. Capabilities of downloading, applying, building, and deploying patchsets.
  3. Capabilities of replying patchsets in the public mailing lists with Reviewed-by, Tested-by, and inline reviews.

I use the term patchset instead of patch, because a patchset is a logical set of patches pertaining to the same context, while a patch is any individual change sent as a message. For reviewing, considering chunks of related changes instead of individual changes makes more sense. Just think of reviewing a Pull Request in its whole context, versus reviewing the commits of this PR independently.

First Cycle: Understanding the Problem and Building the Core

Since my proposal, my better understanding of the problem at hand along with my interactions with my mentors, made me realize that the most important deliverable was to provide a reliable UI to lore.

We didn’t plan on having strict development cycles, but looking in hindsight, I can divide my work on kw patch-hub into 3 development cycles. The first cycle was related to experimenting and understanding the problem and building the feature’s core.

How we kept Organized

From an organizational perspective, we documented every starting requisite in issues and added them to a GitHub Kanbam board. Below is a print of it, just for illustration purposes, but you can check its live state here.

kw patch-hub Kanbam

Every time we encountered some kind of bug, or discussed/thought of a possible improvement, we added an entry to the ‘To Do’ list, even if was just a draft that would promptly altered or removed. This sort of “protocol” was really important to keep track of what needed to be done.

Studying and Expanding the Code

From the code perspective, I focused on understanding what was already done, what needed to be done, what needed to change, and built the core of kw patch-hub. About two years ago, my mentors Rodrigo Siqueira and Melissa Wen implemented what we can call the “predecessor” of kw patch-hub named kw upstream-patches-ui. This was mostly a prototype that validated the feature, but that laid the foundation needed for my project.

At the end of this cycle, kw patch-hub started to look functional and the feature software architecture was somewhat solidified (although, as we will see in a moment, kind of messy). At that moment, the feature was still named kw upstream-patches-ui and looked like this:

kw patch-hub First Cycle

Contributions of First Cycle

From mid-May up until mid-June, those were my contributions in the form of Pull Requests, in chronological order of merge:

Pull Request Nº of commits
documentation: dependencies: Add curl and xpath dependencies 1
src: upstream_patches_ui: Add help option 1
src: upstream_patches_ui: Fix list_patches menu title 1
src: upstream_patches_ui: Add loading screen for delayed actions 1
src: upstream_patches_ui: Add bookmark feature 5
src: upstream_patches_ui: Fix Dashboard screen message box 1
src: lib: lore: Use b4 tool for downloading patch series 1
Add Bash and Zsh completions for upstream-patches-ui 2
src: upstream-patches-ui: Add basic feature documentation 1
Add ‘Settings’ menu for upstream-patches-ui 6
upstream-patches-ui: dialog’s severe bugs with certain arguments 2
src: upstream_patches_ui: Fix ‘New Patches’ screen title bug 1
src: upstream_patches_ui: Replace undefined help function call 1
src: upstream_patches_ui: Fix relative paths in ‘Kernel Tree Path’ 1

In this cycle, we also worked on a PR for integrating kw patch-hub with kw build. We came to a working version but decided to not introduce this enhancement before cleaning the code. Nevertheless, this PR produced some good commits that were merged into the project:

Time to Clean

kw patch-hub had its core screens implemented (Dashboard, Registered Mailing Lists, Bookmarked Patchsets, Settings, Latests Patchsets), but it lacked a reliable fetch strategy of patchsets from lore, that limited patchsets from a hardcoded period of time, and the whole feature needed a refactoring, as its architecture was starting to break and the code had some bad smells.

Second Cycle: Refactoring

As mentioned, kw patch-hub had a core implemented, however, the feature badly needed refactoring.

At this point, the feature was implemented across three files: 2 library files (src/lib/ and src/lib/ and one that represented the feature itself (src/ The Model-View-Controller was softly implemented in a way that src/lib/ was the Model, src/lib/ was the View, and src/ was the Controller.

Refactoring the Controller

I described in a previous post the Finite-State Machine computation model used to implement kw patch-hub Controller, but the thing was that for each new state added, src/ grew uncontrollably. At one moment, the file was more than 500 lines in size with functions that didn’t follow a logical order, which made it harder and harder to scroll to the desired line each time an addition was made. To exemplify the need for refactoring on this Controller front, there was a switch-case with more than 100 lines.

The Controller refactoring was made by taking advantage of the Finite-State Machine model implemented and breaking down the file into smaller files that roughly represented the states. Thanks to these extractions that resulted in great modularity, both maintaining and expanding the feature was made much easier from this point onward, as I could isolate problems to single files, lower the complexity and coupling of the code, whilst also introducing somewhat of a pattern for Finite-State Machines to kw project.

Now the Controller files are stored in src/ui/patch_hub and look like this:

kw patch-hub Controller Refactoring

Refactoring the View

Another badly needed refactoring was in the View front. The file src/ mostly stored library functions to create dialog boxes. These dialog boxes are the means through which kw patch-hub displays screens, hence, the View role the file performed (it is worth noting that this role is from kw patch-hub perspective, as the library file should be general enough to be used all around the kw project).

These functions were really similar and two actions that were exactly the same in each and every one of them were: building the preamble of the dialog command and evaluating the dialog command built. These two actions were extracted to functions, reducing a lot of duplicated code, whilst also allowing for more fine-grained testing. In the refactoring, I took the opportunity to also enforce some patterns in the View.

Defining the feature’s new name

This may not be a refactoring, but as we are essentially changing names to improve the feature, I will consider it here. The name change was urged since the start of GSoC, and in this second cycle moment, we decided to pull the trigger. I opened a poll to decide the feature’s new name and kw patch-hub was elected.

Contributions of Second Cycle

From mid-June up until the start of August, those were my contributions in the form of Pull Requests, in chronological order of merge:

Pull Request Nº of commits
upstream-patches-ui: Controller refactoring 3
src: patch_hub: Rename upstream-patches-ui feature to patch-hub 1
patch-hub: Revise ‘Patchsets Details and Actions’ screen 7
patch-hub: Refactor lore mailing lists screen 4
src/lib/dialog_ui: Reduce duplicated code and add pattern to file 4
patch-hub: Fix bug and refactor ‘Registered Mailing Lists’ screen 3
src: ui: patch_hub: patch_hub_core: Fix ‘Registered Mailing Lists’ message box 1

Third Cycle: Consolidating Interaction with Lore API

After the two first cycles, we tackled what was considered from the onset of the program the critical point: the interactions with lore API, especially to fetch an arbitrary number of patchsets reliably, allowing the user to potentially navigate all of a mailing list history. It is important to note that, in case this problem couldn’t be solved, the whole feature would be jeopardized as its functionality would be really limited.

The Problem and the Solution

I plan on making a more detailed post on the lore API, but in summary, lore provides a search engine powered by Xapian that allows us to make queries to match specific messages in a given public mailing list archived.

The implementation, at this point, used a hardcoded period of time (last 2 days) to query lore for patches and we needed a way to fetch adjacent chunks of patchsets that had a consistent order.

After deeply studying the lore API, or, should I say, reverse-engineering it, I came up with an answer that both solved the problem and eliminated the need for managing timestamps to get consistent chunks of patchsets.

Current Merged State of kw patch-hub

All this blabber aside, below is a demo of using kw patch-hub to navigate through the amd-gfx list history. This demo is the current merged state of kw patch-hub. Notice that the feature paginates the patchsets and doesn’t do redundant fetches when going back on pages.

kw patch-hub Current State

Contributions of Third Cycle

This whole cycle is contained on this Pull Request with 9 commits that was active from the start of August until some days ago:

kw patch-hub: Add reliable fetch of latest patchsets from mailing list

Next Steps

As a result of my GSoC project, kw patch-hub can be used as a reliable UI to the lore archives and provides some other functionalities like bookmarking patchsets, downloading applicable patchsets (to a default or custom directory), and managing the feature’s settings through the feature itself.

It’s important to note that kw patch-hub has become an integral part of my Capstone Project, so I’ll keep updating the feature until the end of this year, and probably further than that.

Here is a list, not in order of importance, of the next steps to take that will make kw patch-hub incrementally better. By tackling all of these, I firmly believe the feature will provide a solid experience for users, especially for patch-reviewing.

  1. Optimize fetch time. In the demo GIF above you can see that loading times are not good.
  2. Fix parsing of patchsets. In the demo GIF above you can see some patchsets metadata malformatted/incorrect.
  3. Add an ‘Apply’ action for patchsets.
  4. Add a ‘Build’ action for patchsets.
  5. Add a ‘Deploy’ action for patchsets.
  6. Add query based on string. In other words, integrate a more refined search of lore archives on the feature.
  7. Allow users to reply patchsets with ‘Reviewed-by’, ‘Tested-by’, and with inline reviews.
  8. Improve feature UX.
  9. Refine feature fixing bugs.
  10. Improve loading screens. They are static and don’t give much feedback to the user.


First, I want to give special thanks to my mentors Rodrigo Siqueira, Melissa Wen, Paulo Meirelles, and Magali Lemes. They were always very attentive and open to communication. They also were really considerate of me when giving feedback and would often take a step back to explain concepts or point me in the right direction. I couldn’t wish for better mentors, so thank you all so much.

I also want to thank my colleague Aquila Macedo who also actively contributes to kw and was there at every weekly kw meeting.

Finally, I want to thank The Linux Foundation for giving kw and me the opportunity to participate in GSoC23.

Written on August 26, 2023

Articles from blogs associated to kw developers

GSoC23 Final Report

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 proposal was to develop a feature for the kw…

via August 26, 2023

AMD Driver-specific Properties for Color Management on Linux (Part 1)

TL;DR: Color is a visual perception. Human eyes can detect a broader range of colors than any devices in the graphics chain. Since each device can generate, capture or reproduce a specific subset of colors and tones, color management controls color conversion…

via Wen.onweb August 21, 2023

Generated by openring