The next Ubuntu Touch major release is approaching rapidly, yesterday we reached a major step in the preparation of the upcoming Ubuntu Touch 24.04-2.0 release: The branching-off (see below on what that is).

Ubuntu Touch 24.04-2.0 Beta is Now Available

Part of this development release step is the publication of the 24.04-2.0 Beta release images, for more details and information see:
https://ubports.com/blog/ubports-news-1/ubuntu-touch-24-04-2-0-beta-is-n...

And additionally, find below some background information on how we maintain various Ubuntu Touch releases in parallel via Git(Lab). In fact, the release model of Ubuntu Touch has partially been adopted from how we in Debian maintains our various Debian versions in parallel, only that in Ubuntu Touch we use Git(Lab) for maintaining the different package versions and not, like in Debian, the APT archive itself.

What does 'Branching-Off' Mean?

Last Saturday, in the UBports Q&A, I explained Ubuntu Touch's "branching-off", an aspect of the Ubuntu Touch release workflow based on Git(Lab). To make this accessible to even more people, here it comes as a write-up:

We host many Git repositories on GitLab, and our primary work is done on the main branches, which contain the bleeding-edge code. When a merge request is deemed critical for stable versions of Ubuntu Touch, we cherry-pick it into a release series branch.

Currently, we land our changes in the main branches and then cherry-pick them to the ubports/24.04.1.x branches. The 'branching off' process for the upcoming 24.04-2.x release means that our current main branches will be copied over to create new branches for this release cycle, namely ubports/24.04-2.x.

This has two major implications. First, any item that hasn't been translated by the time of the branch-off will not receive any more translation updates during the 24.04-2.x cycle. This is why it is crucial that translation work is completed before the branching-off.

Warning of Breaking Changes arriving soon in 26.04-1.x Daily Development UT Images

Second, looking ahead to the release after 24.04-2.x, we will be approaching 26.04-1.x. The OS base will change to Ubuntu 26.04 LTS, hopefully being ready for release to Ubuntu Touch users before the end of the year. We already have a list of features we want to land there. Because we plan to include various major changes, such as the switch from Mir 1 to Mir 2, new calendar and contacts backends, Qt6-based core apps and service components, etc., the likelihood of breaking changes at the beginning of the 26.04-1.x release cycle (which will become the next main branches' target) is very high.

The Ubuntu Touch 24.04-2.0 Release Schedule

The current release schedule is estimated to be:

25 May 2026 [done]
Platform stability freeze 24.04-2.x

25 May 2026 [done]
String freeze 24.04-2.x

15 June 2026 [done]
Branching-off (and unfreeze 26.04-1.x development), UT image release: 24.04-2.0 Beta

22 or 29 June 2026 [coming]
Final freeze for 24.04-2.x, UT image release: 24.04-2.0 RC

6 or 13 July 2026 [coming]
Release version 24.04-2.0

16 Jun 2026 11:14am GMT

In 2008, I landed my second job, in the network team at Orange Portails, the division behind the websites and search engine of the French telecom operator Orange. The place ran like clockwork: a comprehensive technical setup, a dedicated team for every part of the business, and room to focus on what I do best. A few years later, none of that mattered: thanks to an obsession with the numbers, we could no longer deliver new services on time.

The first years

During my first years, the department operated like a startup. Its cradle was the French company Echo. They built a search engine. France Télécom bought it and renamed it Voila. It was the most visited search engine in France in the early 2000s. France Télécom consolidated the portal activities into the Wanadoo Portails division, later renamed Orange Portails.

The technical environment was excellent. We had many internal tools:² a ticket system, an RRD-based graphing tool, an IPAM, a reporting tool, and an SNMP-based alerting tool.³ We deployed our Linux servers with CFEngine. We installed systems and applications from internal Debian repositories. We documented everything in a private MediaWiki instance. Supervision was performed with an ancestor of Xymon. The network architecture was clean and scalable with little legacy. We onboarded new people in a day.

It was a nurturing environment for me. I developed several tools: lldpd, an 802.1AB implementation, Snimpy, a pythonic binding for Net-SNMP, Wiremaps, a layer-2 discovery tool with a time machine to know which device is connected where, Kitérő, a tool to simulate network conditions, QCSS-3, a controller for load-balancers, and ipoo, a service available through a Jabber chatbot and a Greasemonkey script to expose IP-related information. I added SNMP support for Keepalived and Quagga. I also started this blog, with articles like "Anycast DNS," TLS-related articles like "TLS computational DoS mitigation," SNMP-related articles like "Integration of Net-SNMP into an event loop," Linux-related articles like "Tuning Linux IPv4 route cache," and an article about VXLAN long before it was cool.

The collapse

When we needed new servers, the on-site team would take a set from the inventory, install our base Linux distribution on them, put them in the datacenter, and cable them to the top-of-the-rack switches. We opened a ticket describing the servers we needed, and one week later, our servers were available. 💫

Orange wanted to know if this team was performing well, so they asked for KPIs. They decided to use the number of tickets completed in a year. They asked to double this number. So instead of one ticket for a new service, we would open six tickets-one per server. By the end of the year, the KPIs had more than doubled.

Everybody saw it as a success for performance management. So, they asked to do the same for the next year. Now, we needed to open a ticket per server and per step. Again, the KPIs doubled. Behind the scenes, the tickets went to different people and were no longer handled in order. So, for the next year, it was decided to have meta-tickets and meetings to follow the progress of these tickets. Of course, all these extra steps pushed the KPI even higher.

This performance management method spread to the other teams.⁴ Everything became slower. Instead of a couple of weeks, a new service now took six months. We built a Soviet nail factory. But the KPIs were good, and we stopped caring.

Let me give you another example. We had to estimate the impact of each night operation. We weren't half bad: we declared most operations "without any expected impact." Most of the time, there was no impact. One time out of five, there was a 5-second impact. We were told to try harder to meet our expected impact. What did we do? We started declaring a 5-second expected impact. One day, we got a 30-second impact and were told we failed to match the expected impact. In the end, we declared most operations with a 10-minute expected impact, and we stopped caring: instead of carefully shifting traffic around, we allowed ourselves a 5-minute impact. And our KPIs were never better.

An artist's rendering of the evolution of impacts over the years.

---

KPIs are not bad, but they are easy to break. Use them carefully: let the people doing the work help choose the metrics, and tie those metrics to the quality of the service-for example, with service level objectives. Otherwise, even dedicated people stop caring, game the system, and eventually quit. 📊

16 Jun 2026 6:26am GMT

I have proposed the deletion of an obsolete script, but it makes me feel complicated feelings so I'm going to try and express those. This particular script was written in 2014, but the concept goes back much further - before git was invented.

When I started university in 2003, I seem to remember the computing society used to run tutorials for first-year students on how to use Apache Subversion for your group project - a vast upgrade on CVS (or worse, no version control at all). Back then, the idea of viewing your changesets in a web browser was relatively new - while it was possible to look at an SVN repository through a web UI, features were limited unless you installed something compicated like Trac.

Figure 1: Data flow when distributing commits via a mailing list

Perhaps because reading email on your desktop computer (I don't think I could afford an IBM ThinkPad?) was the only vaguely real-time notification system available at the time (except I guess SMS, which cost 10p per text), a common pattern seemed to be to use a post-commit hook to send every single commit to a mailing list, named something like 'foo-commits'. Indeed, for a long time Fedora had an scm-commits list which appears to be a topic of recent discussion.

I can't really explain why people wanted to have every commit sent to a mailing list except as a way of getting notified of activity - I can't believe people would import raw patches from those lists, ala LKML, rather than run actual version control commands to fetch the new source directly. Maybe you'd have to go back to NNTP for this.

I do like the vendor-neutrality of the "everything-as-text" approach, building on the open ecosystem of SMTP. But I doubt we'd see a widespread resurgence of commit lists now - most code hosting must allow anyone to subscribe to email notifications, I assume, and I don't see a huge benefit in a mailing list archive of commit messages.

In the case of seL4, I'm even more confused about why this script was committed in 2014, shortly after the kernel was put on GitHub. I can only assume it was imported from previous infrastructure. I do know that the implementation is quite Python 2 heavy, with the conversion between unicode and bytes featuring heavily. So rather than risk breaking its logic with patching, I think it's time to "thank it for its service" and let go.

15 Jun 2026 10:04pm GMT