Ian Jackson: Free Software, internal politics, and governance
There is a thread of opinion in some Free Software communities, that we shouldn t be doing politics , and instead should just focus on technology.
But that s impossible. This approach is naive, harmful, and, ultimately, self-defeating, even on its own narrow terms.
comments
- Today I m talking about small-p politics
- Many people working together always entails politics
- Consensus is great but always requiring it is harmful
- Governance is like backups: we need to practice it
- Governance should usually be routine and boring
- Governance means deciding, not just mediating
- On the autonomy of the programmer
- Mitigate the consequences of decisions retain flexibility
- But don t do decisionmaking like a corporation
- If you won t do politics, politics will do you
- Conclusions
- Respect and support the people who are trying to fix things with politics.
- Be informed, and, where appropriate, involved.
- If you are in a position of authority, be willing to exercise that authority. Do more than just mediating to try to get consensus.
Another short status update of what happened on my side last month.
Notable might be the Cell Broadcast support for Qualcomm SoCs, the
rest is smaller fixes and QoL improvements.

For a long time I ve been wanting to try GitOps tools, but I haven t had the chance to try them for real on the projects
I was working on.
As now I have some spare time I ve decided I m going to play a little with 
Like each month, have a look at the work funded by
Back when I setup my home automation I ended up with one piece that used an external service:
Hi, I m Melissa, a GPU kernel driver developer at Igalia and today I ll be
giving a very inclusive talk to not let your motivation go by saving time with
kworkflow.
So, you re a kernel developer, or you want to be a kernel developer, or you
don t want to be a kernel developer. But you re all united by a single need:
you need to validate a custom kernel with just one change, and you need to
verify that it fixes or improves something in the kernel.
And that s a given change for a given distribution, or for a given device, or
for a given subsystem
Look to this diagram and try to figure out the number of subsystems and related
work trees you can handle in the kernel.
So, whether you are a kernel developer or not, at some point you may come
across this type of situation:
There is a userspace developer who wants to report a kernel issue and says:
What s the problem of this situation? The problem is that you keep creating new
scripts!
Every time you change distribution, change architecture, change hardware,
change project - even in the same company - the development setup may change
when you switch to a different project, you create another script for your new
kernel development workflow!
You know, you have a lot of babies, you have a collection of my precious
scripts , like Sm agol (Lord of the Rings) with the precious ring.
Instead of creating and accumulating scripts, save yourself time with
kworkflow. Here is a typical script that many of you may have. This is a
Raspberry Pi 4 script and contains everything you need to memorize to compile
and deploy a kernel on your Raspberry Pi 4.
With kworkflow, you only need to memorize two commands, and those commands are
not specific to Raspberry Pi. They are the same commands to different
architecture, kernel configuration, target device.
I don t know if you will get this analogy, but kworkflow is for me a megazord
of scripts. You are combining all of your scripts to create a very powerful
tool.
This is the list of commands you can run with kworkflow.
The first subset is to configure your tool for various situations you may face
in your daily tasks.
So how can you save time building and deploying a custom kernel?
First, you need a .config file.
Then you want to build the kernel:
Finally, to deploy the kernel in a target machine.
You can also save time on debugging kernels locally or remotely.
You can save time on managing multiple kernel images in the same work tree.
Finally, you can save time when submitting kernel patches. In kworkflow, you
can find everything you need to wrap your changes in patch format and submit
them to the right list of recipients, those who can review, comment on, and
accept your changes.
This is a demo that the lead developer of the kw patch-hub feature sent me.
With this feature, you will be able to check out a series on a specific mailing
list, bookmark those patches in the kernel for validation, and when you are
satisfied with the proposed changes, you can automatically submit a reviewed-by
for that whole series to the mailing list.
Eight months ago I came up my rocky driveway in an electric car, with the
back full of solar panel mounting rails. I didn't know how I'd manage to
keep it charged. I got the car earlier than planned, with my









Last year, I decided to start participating in the Debian LTS and ELTS projects. It was a great opportunity to engage in
something new within the Debian community. I had been following these projects for many years, observing their evolution
and how they gained traction both within the ecosystem and across the industry.
I was curious to explore how contributors were working internally especially how they managed security patching and
remediation for older software. I ve always felt this was a particularly challenging area, and I was fortunate to
experience it firsthand.
As of April 2025, the
After careful consideration, I ve decided to embark on a new chapter in my professional journey. I ve left my position at AWS to dedicate at least the next six months to developing open source software and strengthening digital ecosystems. My focus will be on contributing to Linux distributions (primarily Debian) and other critical infrastructure components that our modern society depends on, but which may not receive adequate attention or resources.
Fun with -fsanitize=undefined and Picolibc
Both GCC and Clang support the -fsanitize=undefined flag which
instruments the generated code to detect places where the program
wanders into parts of the C language specification which are either
undefined or implementation defined. Many of these are also common
programming errors. It would be great if there were sanitizers for
other easily detected bugs, but for now, at least the undefined
sanitizer does catch several useful problems.
Supporting the sanitizer
The sanitizer can be built to either trap on any error or call
handlers. In both modes, the same problems are identified, but when
trap mode is enabled, the compiler inserts a trap instruction and
doesn't expect the program to continue running. When handlers are in
use, each identified issue is tagged with a bunch of useful data and
then a specific sanitizer handling function is called.
The specific functions are not all that well documented, nor are the
parameters they receive. Maybe this is because both compilers provide
an implementation of all of the functions they use and don't really
expect external implementations to exist? However, to make these useful in an
embedded environment, picolibc needs to provide a complete set of
handlers that support all versions both gcc and clang as the
compiler-provided versions depend upon specific C (and C++) libraries.
Of course, programs can be built in trap-on-error mode, but that makes
it much more difficult to figure out what went wrong.
Fixing Sanitizer Issues
Once the sanitizer handlers were implemented, picolibc could be
built with them enabled and all of the picolibc tests run to uncover
issues within the library.
As with the static analyzer adventure from last year, the vast bulk of
sanitizer complaints came from invoking undefined or
implementation-defined behavior in harmless ways:















Dear Debian community,
this is bits from DPL for March (sorry for the delay, I was waiting
for some additional input).
Conferences
In March, I attended two conferences, each with a distinct motivation.
I joined FOSSASIA to address the imbalance in geographical developer
representation. Encouraging more developers from Asia to contribute to
Free Software is an important goal for me, and FOSSASIA provided a
valuable opportunity to work towards this.
I also attended Chemnitzer Linux-Tage, a conference I have been part of
for over 20 years. To me, it remains a key gathering for the German Free
Software community a place where contributors meet, collaborate, and
exchange ideas.
I have a remark about submitting an event proposal to both FOSDEM and
FOSSASIA:
Cross distribution experience exchange