Planet GNOME

LinuxDays 2026, the largest open-source event in Czechia, took place on the first weekend of October, and we had a Fedora & CentOS booth there again. This time, we got a smaller table and our booth equipment was more modest because no one traveled from Brno by car—we only had what we could carry on the train. However, we had quite a few nice stickers and one Framework laptop, which generated a lot of attention again.

I was happy that I didn’t have to staff the booth alone; I was accompanied by Vojtěch Trefny, a long-time Fedora contributor.

Even though CentOS Stream has existed for seven years now, we still received questions like: “Oh, CentOS is still alive? I thought Red Hat killed it a long time ago.” This was typically the starting point for a conversation about the differences between the original CentOS and CentOS Stream, as well as their relation to Red Hat Enterprise Linux.

Most questions about Fedora were related to Framework, which didn’t come as a surprise given that we were showcasing Fedora Linux 45 on a Framework Laptop 16. People asked whether there is any cooperation between Fedora and Framework, whether Fedora Linux is a good OS for Framework hardware, and whether Framework is a good laptop option for Fedora Linux. To all of that, we had very positive answers.

It was an exhausting weekend because we had dozens of conversations, but it was also refreshing to meet Fedora and CentOS users and hear feedback directly from them. I’d like to thank Fedora for sponsoring my trip and Vojtěch for helping me with the booth.

No single person can know everything happening in Fedora at any given time. I say this often in our community, half as a warning and half for comfort. For a while, I did not really believe it applied to me. I wanted to know everything. I joined new teams, participated in tickets, and either participated or led meetings across the project. Surprisingly, as a young university student, I held a vast amount of it in my head.

But Fedora does not stand still long enough for that to last. Eventually, I was spread thin across more teams than I could realistically track. As my academic load increased or I began an internship, promises I made quietly fell off my radar. It was not because I did not care. It was because the systems I used to track them could not keep up with the sprawl, when my available time to contribute changed.

However, as I reentered the Fedora community as a Red Hat employee, the same systems I used as a student were challenged. As I get going with my new role, I am rethinking how I can rebalance my bandwidth sustainably. So, this post is about how I started managing multiple Git repos with AI agents to claw back some of that bandwidth. It is not really a story about a remarkable tool. It is an argument that in a project this sprawling, protecting your attention is the real win. I will cover two moments when things fell through the cracks, the workflow I built to catch them, a real example of it working, and an honest take on trusting AI when it sometimes gets things wrong.

Why managing multiple Git repos gets hard at Fedora’s scale

Fedora is sprawling. Fedora’s distribution Git (dist-git), the home for package sources, holds something like 20,000 packages. Add the team and SIG repositories that coordinate the people behind those packages on Fedora Forge, and the number of places where decisions get made is enormous. Yet, most contributors only touch a handful of them. However, even a handful is often scattered across different platforms, with no single view of all of it.

Where things fell through the cracks

Before this workflow, it felt like pure chaos, and I have the scars to prove it. Fedora runs on mailing lists, Fedora Discussion topics, Matrix chat rooms, and Fedora Forge issues/tickets. Furthermore, all of these are spread across dozens of teams, Working Groups (WGs), and Special Interest Groups (SIGs). In short, there are a lot of different places to follow a lot of different things.

For a long stretch, the Fedora Marketing Team had a backlog of tickets. In a few cases, contributors asked for talks and presentations to be uploaded to the Fedora YouTube channel. I had the access to do it and other YouTube maintainers were no longer active, so therefore, it was quietly mine to own. I saw the tickets at least once, but I was overworked and busy with higher-priority work. The YouTube videos slid off my list. A new volunteer eventually picked them up months or even a year later.

Additionally, Fedora also runs meetings well… on paper. Fedora holds virtual text meetings in Matrix chat rooms with a bot that logs everything. Each meeting has a clear start, a clear end, and annotated topics. But a faithful log is not the same as follow-through. For example, in AI/ML SIG meetings, we discuss a decision or someone takes an action item, and it gets logged. But it does not always make it back into the relevant ticket or discussion post. The record exists, but it does not connect itself to the places that need updating.

Patterns like this repeat themselves. The examples above are merely specific examples of where things fall through the cracks. However, there are things like this that happen everyday in different corners of the community too.

The AI multi-repo workflow

So, here is the workflow I use now. It does not get rid of all the chaos, but it helps me manage it much better. First, I point an LLM-gen-AI agent at a directory holding several cloned Git repositories. For example, the AI/ML SIG docs repository, AI/ML SIG tickets repository, and Agent Skills library. Then I ask it to analyze across all of them.

I also feed it meeting logs or summaries. I ask it to cross-check them against open tickets and Fedora Discussion topics:

• Did we document the decisions?

• Did we track the action items?

• Is anyone still waiting on a reply?

Critically, I do not want it reading only files from my local git clones. I want it to query the remotes too: the Fedora Forge API, issues, discussions, and more. The underlying Forgejo API is enormous. It lets the agent track the actual cadence a team works at, not just a snapshot.

A word on trust and hallucination

I have to be honest here: the agent sometimes gets things wrong. It will occasionally misread a thread or hallucinate a detail. However, I do not think that disqualifies it. Humans get things wrong too. I would rather have slightly imperfect visibility into tens, hundreds, or even thousands of repositories than none at all. Ultimately, the question is not whether the agent is ever wrong. The question is what level of risk you are willing to accept for the visibility you gain.

A real example: Reviewer guidelines across three repos

Our Fedora Agent Skills Library needed reviewer guidelines. Laura Barcziová (@lbarczio), on our reviewer team, wrote a solid REVIEWING.md in the ai-ml/skills-library repo. But our separate ai-ml/docs repository only had a page on creating a skill, and nothing on reviewing one.

I used an agent in OpenCode to pull discussion context from Fedora Forge issues about our reviewer process. It helped me reconcile that context with Laura’s draft. Then I orchestrated multiple Pull Requests across the repositories at once. This brought the AI/ML SIG docs site in line with what the team had actually decided.

The real payoff is not the tool

In conclusion, the payoff is that it hands me back the capacity to zoom out. In a project where nobody can hold it all in their head, something should watch dozens of repositories. It surfaces what changed and what needs to catch up. That means I can engage with people’s feedback instead of just surviving the volume of it. When someone takes the time to review my Pull Request, I want the bandwidth to genuinely consider what they said. I do not want to just clear my queue.

I hope this overview of my flow and process is insightful. As of yet, I do not have a commenting feature on my blog, although I am looking into this. Tag me in a LinkedIn post and we can continue the conversation there.

I remember back in 2020, people were complaining that we didn’t have enough documentation for creating GNOME Shell extensions. They said it was almost impossible to figure out where to start. They were right, learning all of it without proper documentation was a huge challenge for me too.

So, I decided to learn the GNOME Shell source code and shared what I learned in a YouTube tutorial series. I spent countless hours learning and making those videos, and the community was very happy to finally have guides and documentation.

On the GNOME side, Sriram Ramkrishna started the GNOME Extensions Rebooted project. When he noticed my tutorials, he invited me to join the team to help write documentation. I spent many hours learning GTK4 and the GNOME Shell 40 source code to write the famous GNOME Shell 40 Port Guide. I’d argue that many extension authors would have given up without it. Migrating from GTK3 to GTK4 and adapting to the changes between 3.38 and 40 was overwhelming. I wrote the guide with many examples, so developers could easily understand how to port their code.

Today we have all the documentation needed to start and maintain extensions, but nowadays, people are just simply vibe coding GNOME Shell extensions without reading any of it before submitting it to EGO. To be honest, in the age of LLMs, it feels like our documentation is feeding LLMs more than actual human developers.

For years, I tried my best to help the community, answering questions daily and reviewing extensions submitted to EGO, often spending 4 to 10 hours a day managing the whole extensions eco system. GNOME was incredibly generous this year and awarded me the GNOME Pants Award 2026 for my contributions to GNOME and the extensions ecosystem. That was a major personal milestone, and honestly, a testament to the growth of our community as a whole.

I’m writing this post because since early 2025, the volume of submissions has exploded. The vast majority are AI generated, and the huge workload is pushing me close to burnout. To be clear, all of my work is unpaid. While managing this volume easily matches a full-time job, my monthly donations remain close to zero. Given how many people use GNOME extensions daily, I truly believe our community can help make this workload doable. If you find value in what I do or if my work has helped you out over the years, please consider supporting me through donations. Without financial support, I simply won’t be able to keep going at this pace.

AI generated extensions, especially when prompted by non developers are frequently bloated and poorly designed. Because extensions run directly inside the GNOME Shell process, quality control is critical. Low-quality, AI generated code directly threatens the stability of the entire shell, and vibe coders need to realize that. As someone who reviews code across all of EGO, I can tell you that LLMs produce needlessly complex, hard to read code that takes significantly longer to review. To make matters worse, some submitters rely on AI to generate replies during the review process. I even received a response that accidentally pasted the LLM’s instructions intended for the user:

Then, respond to the specific points it points to and maintain a real public repository, with testing instructions and development history. This gives the base reviewer to evaluate maintenance and quality, without trying to hide anything.

On a positive note, a while back I published An Open Letter to AI for Generating GNOME Shell Extensions to fix specific code patterns their models were generating incorrectly and I noticed most of those issues disappear just a few weeks after that post, which is great news, but also proof of just how heavily our documentation is feeding these LLMs.

Anyway, we need viable solutions to keep the EGO ecosystem stable, trustworthy, and sustainable:

• I’m asking developers who understand GTK and GNOME Shell source code to join the review team. I am happy to mentor and teach you the review process. Please note that while this is a volunteer role, we need people who can be consistently available during the week.
• As many of you know, we introduced the Shexli linter a few months ago to make the review process easier. We need someone to help us improve it. The workflow is straightforward: reviewers identify false negatives and false positives during reviews, and you fix them in Shexli.

If you are interested in joining the review team or helping with Shexli, please reach out to us on GNOME Extensions Matrix channel. Thanks for being part of the GNOME community!

Week 33

This week's icon is for Tau Gärtli's project:
Ripples: "Rip CDs"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Join as a community sponsor to maintain a steady supply of app icons to the Linux ecosystem (every little helps!).

It has been another productive month working on GNOME Design and Community Management as part of my Sovereign Tech Fellowship, and I want to share some of the most interesting developments.

Introduction

I want to begin by highlighting how much the Sovereign Tech Fellowship has changed the conditions under which I contribute to GNOME. As a volunteer, I had to fit my contributions around my day job, working on GNOME in the evenings and during holidays. The Fellowship has enabled me to significantly expand the scope of my work. I can focus more on platform-level design and work on structural changes that make it easier for others to contribute. This type of work reaches many people, and it makes me feel particularly effective.

At the same time, working on GNOME is now my job, which allows me to maintain a much clearer separation between work and free time. I am really enjoying having more time for sports, and I have also started taking regular piano lessons again. I spent the last two weeks of August on holiday in nature and returned feeling refreshed and motivated.

Thank you very much to the Sovereign Tech Agency for this opportunity!

GNOME Circle

GNOME Circle is a certification for high-quality third-party apps that also serves as an educational program for app developers and designers. Unfortunately, GNOME Circle had to close applications in May because the small team of volunteer reviewers could not keep up with the large backlog of unreviewed apps.

Thankfully, several people responded to the call for reviewers, and Tobias recently introduced Sjoerd, Will, FineFindus and me to the review process. Sjoerd was able to start his first reviews of Concessio and Iconic immediately, drawing on the design experience he gained from receiving the Circle review of his app, Graphs. I also started reviewing two apps: Quadrapassel, a Tetris clone, and Mecalin, a keyboard typing lesson app. Quadrapassel is developed by Will, and my review aims to share some of my design experience before he starts reviewing submissions himself. FineFindus has started reviewing Field Monitor, and Tobias and I provided feedback on their review before it was posted publicly.

This represents a significant increase in our review capacity, and I am optimistic that we will soon complete the remaining reviews and then be able to reopen submissions. I would like to thank all previous and current Circle Committee members for setting up and contributing to this program, as well as for reviewing all the excellent GNOME Circle apps. If you want to get involved, reach out on the GNOME Circle Matrix channel.

Scale Row Standardization

Libadwaita provides several types of boxed-list rows for common use cases, such as text entries, password entries, switches, and dropdowns. However, it has so far been missing a row with a scale, which has led apps to implement custom widgets with inconsistent styling. Let’s change that.

I started the Scale Row design process by collecting screenshots of existing use cases and examples of state-of-the-art designs from other platforms. Looking at other platforms is always helpful, but I also needed to take into account the requirements of our design system and its technical capabilities. Because Scale Row will be based on Action Row, it needs to support a title, subtitle, prefix widgets, and suffix widgets. To make the layout work in narrow windows, it also became clear that the scale should be placed below the title. Several rounds of sketching, mockups, and discussion led to the following preliminary design.

Preliminary Scale Row design applied to common use cases

Originally, I intended to design only the row layout and use the scale as it was. However, aligning the start and end of the scale with the labels and icons required us to change the scale’s padding. That change has already landed in Libadwaita, and we decided to take the opportunity to review the scale’s style as well.

I found that the current style does not follow our design system’s 6-pixel grid, and that the knob is smaller than the minimum target size required by the WCAG accessibility guidelines. I therefore proposed several options inspired by other design systems. What we can adjust is largely restricted by what GtkScale technically supports, and I believe we may settle on the proposed pill-shaped style. The pill-shaped knob satisfies the WCAG requirements because a 24-pixel-diameter circle overlaid at the center of its bounding box does not intersect with adjacent targets, such as the scale’s trough. At the same time, the pill-shaped knob does not increase the scale’s height and therefore does not introduce additional whitespace into Scale Row.

While reviewing the scale style, I noticed that an issue filed in 2024 regarding the scale not aligning with the direction of swipes on touchpads had been resolved. Thanks to Carlos, the physical direction of touchpad gestures is now correctly forwarded in GTK, and GtkRange and GtkScale already follow it. This also means that other Libadwaita widgets with semantic motion, such as NavigationView, SplitView, and Carousel, can finally follow the physical swipe direction on touchpads, regardless of whether the user has selected natural or traditional scrolling in the system settings. Alice has already opened a merge request for this change. Ideally, this change should be coordinated with the shell so that gestures such as the three-finger swipe for switching workspaces or opening the overview also follow the physical swipe direction. We also discovered a bug that causes the knob to appear off-center. The bug has technically always been present, but it was less noticeable with the circular knob.

Technically, Scale Row will be based on Action Row. Alice therefore proposed implementing a generic bottom child that also supports other use cases involving widgets below a row header. I included examples such as toggle groups in narrow layouts and a participant list in a calendar event in the mockups to account for their requirements.

Examples of Action Row bottom child use cases A New Era for Calendar(s)

Calendar is where I started contributing to GNOME, and I have spent a lot of time designing for it over the past years. The Fellowship enables me to expand my responsibilities to other apps and shift my focus towards platform-level topics. Nevertheless, designing for Calendar will remain important. From a design perspective, it is one of the most complex GNOME apps and uses many patterns that other apps need as well. This makes it an ideal place to develop design patterns and technical solutions that benefit the entire platform.

At the beginning of September, I finalized a new version of the mockup for Calendar’s top-level app structure, based on discussions I had at GUADEC. Since 2024, we have been discussing Calendar’s top-level structure to define a roadmap for developing a fully adaptive app that works equally well on mobile and desktop. This involves several significant changes, and we have not quite reached that goal yet.

I am therefore especially excited to see multiple contributors implementing parts of the design this month. Hari implemented the new layout, Markus resumed work on his merge requests for touchscreen support and the mobile month view, and Zelda is working on the adaptive event details dialog that will replace the event details popover on mobile. Thank you all!

GNOME Calendar’s week view using the new layout

Recently, the first beta version of Era was released after more than a year of development. Era is a third-party calendar app developed by Titouan in close collaboration with me. You can download Era from Flathub and please report any bugs you find.

Initially, I had some concerns about duplicated development efforts, especially because GNOME Calendar is currently a thriving project with many active and skilled contributors. However, the two projects differ in several important ways that justify developing them in parallel. So far, I believe they have benefited from each other.

One of the main differences is that Era already implements my latest designs including year, month, and agenda views adapted for mobile. These views are used for navigation themselves, rather than relying on separate navigation controls. On desktop you can use the small window side-by-side with other apps for multitasking or go fullscreen for complex planning.

Era’s main window showing the month view

Under the hood, Era is written in Rust and uses Clepsydre, an extensible and modular calendar backend. It currently integrates with Evolution Data Server, while an experimental peer-to-peer backend based on p2panda is also available in development builds. Work towards Android support is underway, and an APK is available through the CI pipeline.

Era’s event dialog showing an event with participants