Diary#1

Friday March 13, 2026

This is going to be the first post in what might become a series of occasional status updates or something like a personal diary. I might overshare or ramble a bit at times and there generally won’t be anything particularly important or interesting here.

I’ve been meaning to write something like this for a while now, but never really found the time or motivation to actually do it. I kind of always liked the idea of keeping a record of what’s going on in my life - my thoughts, experiences, and small updates. It feels nice to know that someday I might be able to look back at these posts and recollect. It also feels nice to share these thoughts, even though I don’t really know who the audience (apart from me) is going to be — if anyone.

I guess I will start this by writing about my health.

I’ve generally been healthy all my life. Apart from the usual seasonal fevers or occasional stomach issues, I’ve never really had any health problems that I can remember. As a result I guess I’ve never did any regular checkups or tried to be consciously healthy like doing exercises. Things changed a bit last November (2025). I developed a fever just before winter was approaching, but this time to my surprise it didn’t come with the usual set of symptoms like runny nose or cold. I didn’t think much of it at first and took some paracetamol. But after 3-4 days it wasn’t going away and I got a little scared. So I went to a physician to get it checked out. During the checkup he measured my blood pressure and the result surprised both of us - 150/110 mmHg. That was unusually high for someone like my age even with a fever. He prescribed me some medication for blood pressure along with treatment for the fever. The fever itself went away after about a week - it was a false alarm, but the bigger problem was my high blood pressure. I got scared a bit more. I took the BP medicine for a week but I was a bit hesitant to continue it after that. I decided to get a second opinion a month later. That time my blood pressure measured to be 160/80 mmHg, which again, was high. However, after discussing things further, the doctor suggested it might be too early to jump straight to regular medication. There was also the possibility of me having whitecoat syndrome. He recommended that I try out some lifestyle changes first to “manage” (see if it naturally decreases) the high BP - things like regular walks, exercise etc. for 3-4 months, after which I was supposed to do a 24-hour ABPM test. So I’ve been doing morning walks for the last three months or so almost daily. I usually walk around 10–12 km a day and I track it in the Google Fit app, which says I’ve logged about 922515 steps over the last four months. It comes out to roughly 7700 steps per day on average which is quite a jump from previously doing almost nothing. Unfortunately I seem to have strained a tendon in my right leg, probably from overdoing it, so I haven’t walked at all this month. Hopefully it will recover by next month. I also completed the ABPM test last week. The daytime and nighttime averages came out to be 124/80 mmHg and 123/75 mmHg and at at the clinic it was 140/80 mmHg. It’s still a bit on the higher side but it has gone down in the last three months. I’ve been also trying to “de-stress” in various ways like reducing my “online” time (more on that later). Hopefully things turn out to be ok.

The next part is going to be a bit about my work and Ph.D.

The latter has been stressful and frustrating lately for various reasons, I won’t really get into. I did manage to submit my first paper to IJB last week. The review process takes quite a bit of time, so I’ll have to wait and see how that goes. In the meantime, I’ve also been working on two more papers. One of them is essentially finished and I’ve sent it to my guide for feedback while I’ve just started working on the other one. I think at this point I just want to get some publications, get the Doctorate and move on to doing my own research independently. I was meant to do the Ph.D. in Algebraic Topology as that was my specilisation during Masters but I didn’t find a guide for it and had to choose Mathematical Biology as a second option. My dream/wish is to do something in Algebraic Topology later on.

This semester I’m also teaching a course on introductory ODEs and PDEs. I finished the ODE portion of the course last week. I used SL Ross' Introduction to Ordinary Differential Equations as a reference which is a pretty standard introductory text on this. We covered definition, formation, classification and existence-uniqueness theorems in January. For first order linear ODEs we covered separable, homogenous, exact and Bernoulli differential equations and for second order ODEs (both variable and constant coefficients, homogenous and non-homogenous) we did the methods of reduction of order, variation of parameters, Euler-Cauchy equations and power series solutions. Personally, I find the method of variation of parameters to be particularly useful so I heavily relied on it. Some people find it to be computationally lengthy, but it can be applied to a wide range of problems and in my opinion, learning a more or less general method like that is much better for the longer term. The mid-semester exams happened last week, so I now have a pile of 40 or 50 answer scripts waiting to be graded.

The next part is about the FOSS stuff I usually do. Most of it can roughly be grouped into three areas - Flathub, Flatpak, and the Freedesktop SDK.

A large portion of my time related to Flathub goes into the main Flathub repository mostly reviewing submissions. I think I started doing this around 2022, and at that time there were three of us reviewing - me, Bart, and Hub. However things changed over time, and reviewing hundreds of submissions every month has its tax to pay. So for the past couple of years it has mostly been just me and Hub handling all the review work. This would normally be fine if not for the constant barrage of the absolute worst, lowest quality AI-generated submission PRs that we get. Reviewing these is hugely frustrating and downright infuriating. Closing them often leads to people sending emails, matrix pings/DMs or opening more PRs, which eventually escalates into arguments and bans. I sometimes get pings when I’m doing something very important IRL (like a few weeks ago, I had multiple pings when doing a blood test) I don’t think anyone deserves to deal with this. I don’t really have a problem with people using AI as a tool to assist them, but alas what we usually end up getting is full-on AI slop without any real human thought or input. I try to be reasonable but it has been very frustrating. I’ve developed and maintain a number of GitHub actions in that repository (and in the flathub-infra org) to automate parts of the review process. The automation helps, but a large portion of the submissions are still difficult to filter automatically and need to be reviewed manually. One of these actions is currently a fairly large shell script. At one point I started converting it to Python, but I ended up dropping the ball on it. I intend to pick it up again at at some point. All of this has also made me lose some of the implicit trust (whatever that means) I used to have. I tend to be much stricter when reviewing and accepting submissions. Looking at the trend of new submissions being accepted, it has noticeably decreased around the time I took over: 674 in 2022, 672 in 2023, 562 in 2024 and around 355 in 2025. The other large time sink here is dealing with various “infra” issues and requests people open, reviewing moderation requests (looking at the DB I reviewed almost 10x more moderation requests than anyone else), maintaining a bunch of Flatpaks (around 19) and dealing with whatever random issues people ping me on.

Dealing with the so-called “Fedora drama” alongside all of this has also been quite frustrating. Fedora maintains its own Flatpak repository built from RPM packages, and from what I could tell it was not particularly well maintained, likely due to limited contributor resources. That in itself is not a problem for me. However, when OBS requested that Fedora stop distributing or at least rebrand the Fedora Flatpak of OBS, I think it would have been reasonable for them to comply. Unfortunately that did not happen, and instead the OBS developers were harassed and strongly criticized. Since their preferred distribution channel was Flathub, it also got pulled into this mess. At the same time, a portion of the Fedora community pushed for enabling the Flathub remote by default. I think Fedora wanting to prefer and promote its own outputs to its users is perfectly reasonable. It is also reasonable if they do not want to enable Flathub by default and simply state that it is blocked because of the above situation. However, instead of saying that directly, what followed was a wave of criticism and arbitrary demands directed at Flathub at both the technical and policy level. Some Fedora contributors also argued that their distribution had superior approaches to these problems. In reality, anyone who has worked on both sides knows that the same kinds of challenges exist across the FOSS ecosystem. Raising concerns or proposing changes is perfectly valid, especially if there is also a willingness to help implement them. That part seemed to be largely absent. The people maintaining Flathub, most of whom are volunteers, can only absorb so much constant criticism and nitpicking from the sidelines. Several Fedora contributors also hold positions in the GNOME Foundation, and later there were attempts to push some of these changes through that avenue as well. Ultimately, I suspect Fedora’s philosophy, and that of some similar distributions, will never fully align with Flathub’s. To me the differences seem fairly fundamental. That said, both sides could still have learned from each other and adopted ideas where it made sense. At least from my perspective, after so much mud being thrown and so much energy being spent, that opportunity now feels largely closed. Ideally, changes like this should develop organically over time, especially when a volunteer run project maintained by only a handful of people is involved. Public criticism from prominent figures rarely helps move things in a constructive direction. Anyways…

Moving on to flatpak-builder-lint, I’m still maintaining it mostly solo. I took over the project in its early days, and at the time it was quite controversial. For the first 5–6 years, Flathub had very minimal build validation, so people weren’t really used to their builds being blocked. When the linter started introducing many new checks (and therefore new breaking changes), it naturally caused a lot of frustration. On top of that, the linter CI wasn’t fully testing everything at the time, which led to additional breakages. Over the past couple of years I’ve tried to stabilise things by improving the existing checks, adding many new ones, removing some vague or problematic ones, and introducing proper CI and test coverage. Whenever breaking changes were introduced, I tried to communicate them by opening issues on affected repositories - at times that meant opening 70–80 issues. I I think all of that effort paid off. Over the past few months I haven’t I really had to add a lot of new code, and the complaints have stopped. These days the biggest time sink there is reviewing exception PRs, which I’m again at it mostly alone. Often this involves looking at the app’s code, running the application itself, knowing about Flatpak and portal developments including what random libraries or frameworks support, asking maintainers questions for context, and making “judgement calls”.

Moving on to the documentation repository, there isn’t much to say here, except that I’m currently the only person actively writing and maintaining the docs. Over the past few year I’ve added a large number of maintenance documents, new policies, inclusion criteria, requirements, and other guidelines. Some of the documentation ends up being fairly technical, since writing it often requires familiarity with the tooling and the underlying code. Similarly, only reviewers who are familiar with the submission process can realistically write the submission and review criteria. I think I’ve done a decent job of keeping everything up-to-date.

Moving on to flatpak-external-data-checker, these days it has more or less turned into another low (read ’no’) activity repository, since as far as I can tell Endless no longer uses it internally, and one of the main maintainers have also become inactive. Over the past year or so I did a couple of sweeps through the issue tracker and landed a number of fixes and new features, with reviews from Will. A year is a long time though, and while writing this I opened the commit log in another tab to remind myself what exactly I worked on. Looking at it now, it seems that most of it is again just me. I guess I’ll simply refer future me at it too.

The next thing is flathub-repro-checker, which I came up with last year. The fact that Flathub stores an application’s sources after the build and that it can be rebuilt from those exact sources with the generated manifest was “common knowledge” to me. However, the process itself was tedious and largely manual. Since I had previously worked on a large number of reproducibility fixes for Freedesktop SDK, and that project used a tool to automate the process, I wanted something similar for Flathub as well. The initial version was a fairly large ~1200 LoC Python script up until version 0.1.10. Recently, I finally managed to find the time to refactor it into a proper project. Bart and I also discussed how it could be deployed for Flathub. I think he ended up doing all the deployment and “hooking” work there but now there is a nice reproducibility dashboard for Flathub.

The next big change for Flathub last year was switching to vorarbeiter. Bart wrote all the code for it. I worked on getting the linter Docker image ready to be used in the Vorarbeiter pipelines. Some of that involved patching flatpak and flatpak-builder at times. I also reviewed some of the initial vorarbeiter code and pointed out a few security issues. Once it was deployed and working, I added a number of smaller features, such as improvements around PR annotations, handling cancelled builds, some bot commands. Since then I’ve continued to push occasional fixes whenever issues come up - usually discovered through random pings, the Sentry dashboard, or other reports. I don’t remember most of it now. Apart from all these, pretty much every repo in the flathub-infra org was touched by me in one way or another last year.

Moving on to Freedesktop SDK, while Codethink helps with the infrastructure and maintains BuildStream and related tooling, most of the general maintenance of the SDK itself has been handled by about 3 to 4 volunteers, including me. I started contributing around 2023, and since then git shortlog tells me that I have the highest number of commits to the project, around 4000 commits spread across nearly 1000 MRs. Alas, one of the long time maintainer unfortunately became inactive last year, and since then I have been handling a large portion of the general maintenance on my own.

The default permissions given to Freedesktop SDK contributors is GitLab’s “Developer” role. However, that is quite restrictive as one cannot retrigger protected branch pipelines, create tags, change scheduled pipelines, or push updates to merge requests from forks. I was fine with this, until being involved meant situations started coming up where a branch pipeline failed and needed to be retriggered, or when I needed to push fixes to a contributor’s merge request. Releases would also sometimes get delayed because the few people with the permissions required to make a release were busy or inactive. Occasionally we also need to make emergency releases when Mesa introduces critical bugs that end up breaking hundreds of Flathub applications at once. Normally, in open source projects, I think after someone has contributed for a long time and invested significant time and effort, they should be given more responsibility and higher permissions, espcially since people with those are being less active. That did not really happen here. Most of that control seems to remain concentrated among Codethink people, who generally do not maintain the SDK itself. This became a constant source of friction for me because I was one of the most active contributors and frequently needed to retrigger branch pipelines or perform other routine tasks. Over the past year or so I asked several times for my GitLab role to be bumped, and also suggested that other active contributors should receive higher permissions as well. Unfortunately that never happened. The contributor who became inactive last year had been working on the project even longer than I had, and they also did not have the permissions they reasonably needed. At one point I had to strongly protest giving “Developer” access to random Codethink people who never has/will contributed to the project and fortunately that stopped.

Another recurring source of friction for me was how some development priorities were handled. Since the SDK is used as a base for certain Codethink stuff, they sometimes assign interns or engineers to work on features they need. This occasionally resulted in large patch sets, the integration of old or difficult to maintain software, or new CI jobs being added without sufficient maintenance capacity. I often pushed back on these changes because they increased the long term maintenance burden for me since I am doing most of it. At times it felt like there was more focus on meeting specific downstream needs than on maintainability and long term stability of the SDK itself. Nevertheless, I am grateful to Codethink for supporting the project through its infrastructure and engineering needs.

The work here also includes several freedesktop-sdk related projects such as the mesa-git extension, the freedesktop-sdk Docker images, the binary seed, and various other pieces of tooling. Most of this work is not very visible. It mostly consists of tedious maintenance tasks such as fixing builds, backporting patches including security fixes, repairing CI failures, and helping decide when ABI breaks or freezes should happen. Occasionally I also had to fix issues in BuildStream plugins. I also developed a few small tools to help automate parts of this workflow. These live in the freedesktop-sdk-utils repository and in the main freedesktop-sdk repository.

One particularly large change last year involved the license work. Among the SDK maintainers it was generally known that we were not installing license files for built modules. However, we were not really aware of the potential legal implications. The “Fedora drama” led a number of distribution maintainers to take a closer look at the project, and the issue of missing license files ended up being amplified significantly. When the confidential issue was opened about it, there was a sense of urgency to address the “problem”. At the time I was not aware that this was a direct consequence of that broader situation. If I had known, I probably would not have been as enthusiastic about jumping in. Nevertheless, I ended up creating the initial framework for handling license installation, with input from Adrian and a few other people. This work was happening in parallel with the upcoming 25.08 release,nand we even had to revive branches from two or three years ago in order to fix them. In the end, I ended up doing a large portion of that work.

Moving on to Flatpak-related work, most Flatpak projects have been fairly dormant for several years, mainly because many of the original maintainers moved on to other projects. As part of the license work mentioned earlier, there was interest in bringing the same license installation framework to flatpak-builder. Sebastian implemented the feature, and through a series of events I ended up reviewing, merging, and creating a release with it. Since Flathub had accumulated a number of patches over time, I also took the opportunity to upstream them one by one. That more or less marked the beginning of my involvement there. Since then I ended up doing a bit of work around flatpak-builder, making several releases, introducing the stable/unstable release policy, cleaning up the issue tracker, fixing various bugs, merging PRs that had been sitting around for years, and adding a bunch of new features along the way. That also somehow spilled over into the Flatpak itself. I ended up reviewing a number of PRs there, merged some fixes, cleaned up parts of the issue tracker, and reviewed a couple of security patches.

I’m not really an expert in C, more so in GLib flavored C. I’m not really a software person either. The only formal programming I learned was basic Python during my Bachelor’s in Mathematics. Most of what I know now I picked up by reading documentation, browsing issues, and looking at other people’s code online. So large C codebases like Flatpak with security boundaries and a long history of stability, and on which so many people depend upon still give me an uneasy feeling. I think flatpak-builder should’ve been written in something like Python, as it is essentially a large “command runner”. Python, for me, has always felt more natural and faster to write and understand. I think it would be great to have the original maintainers like Alex back at everything again but I’m doubtful.

Two other things that take some of my time are documentation work and maintaining most of the generators in the flatpak-builder-tools. Since many of the original maintainers are no longer active, I am now maintaining most of them. Last year I added linting, type-checking, and CI improvements for many of them, fixed several bugs in the node, pip, dotnet, and cargo generators, reviewed and merged the new generator for deno, and I’m currently reviewing the pnpm generator.

That concludes this part about the FOSS work I’ve been doing. I’ve been involved in this for about 4–5 years now, all in my free time, and I’d like to continue doing it for free in my own time. Lately though, the amount of friction and frustration has been increasing, and I’ve been trying (and failing) to take some breaks. To “de-stress”, I’ve turned off notifications for several apps on my phone, and instead of checking emails daily like I used to, I now let them pile up for a few days before going through them. This leads to around 300-400 emails a week but whatever. I think in my time, I’ve seen a lot of projects become inactive. As a result the community around it slowly wanes away, the project looses relevance and gets replaced by something else or becomes a graveyard. I don’t really want that to happen and that has been my main motivation for all this. Rather than writing something new, I try to contribute and help with existing things where possible.

After all of the above I hardly get any free time, but whenever I do I listen to a lot of music and watch YouTube. Sometime in late 2024 I fell into the K-pop rabbit hole through Blackpink, and since then I have been following their music, solo releases, and both their solo and group activities. I follow the pinks on their socials and last year I ended up watching most of their livestreams and fan content on YouTube. I’ve probably exhausted all Blackpink content available on the internet by now and at this point I think it is fair to say that I deeply adore them and am quite invested in them. That also led me to discover other artists such as Lee Hi, Taeyeon, Bol4, IU, AKMU, and Jeon Somi. K-pop also led me into watching K-dramas, and over time I’ve watched quite a few shows. Right now I’m watching Boyfriend on Demand.

Last year I tried to get back into gaming. I bought two controllers for myself (one of them has TMR sticks) and I bought a bunch of games on Steam. I have been playing Dead Cells whenever I find time. So far I’ve only managed to reach the Clock Room stage, but it has been fun.

I think that’s about it for this post. It ended up being quite a bit longer than I expected, but it was nice to reflect on things a a bit.