fidzu : Fedora

15 Oct 2026 8:23pm GMT

14 Oct 2026 7:15pm GMT

The Fedora Project Leader is an interesting gig. The role puts me in conversations about topics that potentially have broad ecosystem impact that go far beyond Fedora as a project. I'm very grateful for the opportunity to inhabit this role because of that. But also I'm humbled by the access I'm afforded. I always approach these conversations with an eye on how these conversations can lead to something with positive ecosystem wide impact.

So the other day I got invited to jump on a call with some people from Epic Games, and I got foreknowledge concerning the new technical approach they wanted to take to implement anti-cheat on Linux based operating systems.

long story short, I'm supportive of their approach. It boils down to having a system where users choose to run their Linux system in specific ways that the anti-cheat system can verify before they are allowed to participate in the gaming platform. It makes use of secure boot, trusted signed vendor kernels ( including Fedora), and BPF code instead of any kernel modules.

I know a high school teacher back in Alaska who would have loved to be able to setup some linux gaming stations for the eSports teams he coached. Is coached the right word for eSports teams? I don't know I'm an old.. I just remember having to run twisted pair networking to run LAN parties.

I don't think they realized at the start of the conversation that I have as much experience with eBPF as I did. Disclosure: my previous gig as a developer advocate with Isovalent (now Cisco) working in the context of the Cilium open source CNCF project, put me into direct contact with eBPF workloads and I was forced to wrap my head around it to do my job. So when they asked me to read over a technical brief over their approach, I was ready to go pretty deep about the approach. But what I did instead was express my impression that their technical approach was probably the best approach I could imagine if I were going to implement something like an anti-cheat system. I also pointed them to the current Fedora Change Proposal that might be relevant to their approach.

But like I said, I always enter these opportunities with an intent to find the ecosystem wide impact. As we got to talking about possible concerns that might be raised with this approach, I offered myself to facilitate a panel discussion where we have some subject matter experts talk through specifics. For myself, even though I have more than a passing knowledge of eBPF, I'm not an expert in its use for this sort of workload, and I'd like to bring someone into a panel discussion with the Epic security team in a public setting to talk about it as a technology. This might be the first end-user desktop oriented use case for eBPF, There's a lot of understanding about it in other contexts.. and I'd like to bring some of that understanding to a conversation in front of a Linux gaming enthusiast audience.

I also want to have someone from Bazzite on the panel. Because Bazzite, as a Fedora downstream, is lazer-focused on this particular use case. Fedora will hopefully be able to integrate some deeper open source changes that simplify the user experience in a broader context, but Bazzite is where I expect everything to come together to provide something seamlessly consumable. I want to make sure we include that perspective in the follow-up panel conversation… if not earlier. I definitely want to have Bazzite devs and this team at Epic talking asap. So I'm heading over to that downstream community as soon as I get this published to see how I can help put them in contact with the right people.

14 Oct 2026 3:59pm GMT

I'm going to be providing dispatches in blog form that detail my learning journey concerning LLMs. I'm going to be experimenting with fully open source inference that I can run locally on hardware I control. Local Language Models; the other LLM.
What utility can I get without reaching for the frontier "as a service" models? Will I have fun? I don't know yet. I've made a commitment to myself to learn, and the way I learn best is experiential. Yeah I was pretty good at textbook learning, but honestly I always enjoyed the homework more than the lectures or the text. So I'm giving myself homework. And I'll be reporting back on my assignments to myself here as blog posts. I'll figure out how to tag or label this so they stand apart as a set of dispatches so that this learning journey can be reviewed in a coherent fashion by future me.

But before I begin all of that, I just want to provide some more thought leadery thoughts to set the stage for why I'm even bothering. Why am I investing my free time in this? Future me, you may be wondering why am I not just studying more curling strategy right now? Good question future me. Let me explain.

Big picture thoughts

The topic of LLMs has been a weebit controversial for the entire open source ecosystem in a way that I've never seen in my personal 20 something year history as self-professed (because we don't have an official business card I don't think - there might be a secret handshake I'm not aware of though) open source enthusiast.

Over the years we've had very opinionated and sometimes heated discussions over disagreements in technology and some standards of practice.. that usually result in forking something; either code or a project community or both. Forking is the fundamental freedom of open source. Forking isn't always the most efficient choice, but it's how the ecosystem at large moves forward sometimes when there is a difference of opinion. It happens more often when its a technical difference in opinion. Forking the code bits is just sort of non-controversial. Our 20+ year old, now defacto standard, collaborative development tool, git, bakes the concept of 'forking' into its operational language. Technical forks are as common as air in the ecosystem now. But sometimes forks are about licensing, and that creates forks around entire project communities and that can be quite controversial when the project contribution community is more than that one person in Nebraska maintaining a codebase alone that we all rely on. Licensing forks tend to make the news. However, forks historically have been very seldomly about developer tool use. Though we did get quite close in the upstream kernel development community in the great bitkeeper use debate that resulted in the creation of git as an open source alternative to a proprietary tool. I find the history of bitkeeper/git instructive. When it comes to concerns over tool use, maybe the right answer is to build an open tool instead of forking a community. Maybe when we build the open tool, we end up unlocking something magically positive and transformative for the entire ecosystem. git was that.

I'm very sure forking in a way where some projects allow the use of this technology and some don't is not going to work out well for us and our collective interests… that being to make sure users stay in control of their technology.

The hard discussion around the LLM flavor of AI goes much deeper and much wider than we are used to debating in the open source ecosystem. I don't think forking our way out of the deep sense of conflict here does anything but depower our shared ability to control the future of this technology. Looking through the history this is probably nearly as significant a discussion as the very idea that software should be copyrightable under US law (instead of being treated merely as instructions.. like cooking recipes) I think the only way through this mess, this very hard discussion, is to stand up fully open versions of this technology.

I think the frontier LLM as a service business model is deeply problematic. I think the fallout from the irrational and unsustainable amount of investment in those "as a service" offerings that have dominated the discussion is unavoidable. A bad business model has poisoned our societal understanding of the utility of the technology. We are reacting to a bad business model that has somehow been allowed to grow beyond the bounds of expected VC risk/reward assessment guardrails. When the investment capital dries up, and these frontier companies can't burn cash any longer, their failures will have global economic impact. I think it's unavoidable at this point.

But I think the technology lives on past that, because the technology is not the business model. I believe all cash burning business model will fail. Its the fate of every start-up that relies on venture capital and can't figure out how to reduce the marginal operating cost per customer as it scales its customer base. I've been in a few start-up environments. I actually like the hustle energy of a start-up. But at some point you have to transition from runway to revenue from mindshare to customers and you must be prepared to pivot business models to get there. You should expect the VC investors will come knocking on a return on investment far sooner than you want them to. And if you're still in startup mode, while also tapping literally all the global investment venture capital liquidity on the planet, and your 10x return expectation to investors is literally more than the entire planet's measurable economic output…. all you've proven is you have a really great pitch deck as a start up founder and you've tapped into some really deep irrational sentiment in the investment class. It's crazy to me how crazy the VC culture has become. THIS IS CRAZY.
Siri, play Crazy Train by Ozzy Osbourne to set the mood.

Preparing for the future

So yeah, I think we are in a bubble and it will pop. But I think the technology continues on in both proprietary and open implementations.. like most technologies do. I finally gave up on my cuecat QR reader and threw it away in the move from Alaska last year. The QR code stuff just never took off like I thought it would.

So I'm preparing for the post LLM business model bubble future. A future where open source takes front and center in how the technology evolves. And in order to do that I need to get hands on with what the state of the art of open source AI is and running it on local hardware (local hardware may mean cloud compute for some people). I finally got myself a new workstation, a Framework desktop with an AMD mainboard, my first personal desktop computer I've bought with personal money in well… to be honest I don't really know. I haven't had a desktop computer since living in Jersey.. I think I moved it to Alaska. My personal computing expenses has been smart phones (shout out to the other FirefoxOS phone owners!), pis, and microcontroller hardware, I've had the privilege of being able to transition work provided laptops into personal machines for years and years. I've kinda taken that for granted. Hey what can I say, startups don't have mature technology asset management.. not something you think about until you get to a certain size.

Thinking globally and acting locally

I could have done a beefy workstation purchase months ago… but I waited until we got the solar power on the house..and that took way too long (thanks HOA rules). But HOA bureaucracy aside, why did I wait until I had solar on the house?

Because I have a very deep ethical problem with how much energy and water resources is going into training LLMs and I wanted to do what I could to offset that. If I'm going to lay hands on the technology at all I need to accept some responsibility for the impact as a user. I know that I can't single-handedly undo the problem. But just like plastics recycling, I can't undo the damage being done by plastics globally either. But I can act locally and mitigate as much as I can while participating in a flawed global system. And I can do that while advocating my geopolitical leadership at all levels to put rational policies in place to fix the systemic problems. I am at peace with how I've chosen to mitigate my own ethical concerns at the start of choice to start interacting with the technology.

I'm trying to figure out how I can go further and make sure my excess solar energy I produce every year can go to a good cause.. still trying to navigate the power company policies to see how I can take control of the excess power I generate so I can direct it to help non-profits instead of just being purchasable power by anyone (especially the data centers). I might not have a great solution for that. The best I can maybe do is get a power purchasing agreement so at the end of the year the power company cuts me a check for my excess power they sold on the open market at wholesale prices. I can then turn around and take that cash and give it to a non-profit. Its not as good as kwh for kwh credit transfer, because I only get wholesale pricing in a purchase agreement so I can't offset the retail cost of electricity for a charity. And it won't feel nearly as good as denying the data centers in Virginia (and there are a lot of them) from being able to use the power I'm generating. But I can, one way or the other, help a non-profit offset their increase in power with my excess; while at the same time lobbying for changes in the energy policy at the state level to make these data centers pay for the infrastructure investments instead of making residential utility customers share that cost.

So here is where I'm at today

I have a desktop capable of being used to do some local language model stuff. I have Fedora Linux running on it. I've followed the basic online instructions on setting up ollama and llama.cpp, using as much as I can from the Fedora Linux rpm package repositories. Thanks AI/ML and Heterogeneous Computing SIGs for the great packaging work that makes it possible for me to just scoop up some things as a user and have a working starting point. And a huge thanks for AMD making the investment to work with the linux upstream community and investing in open source userspace component libraries, so Fedora Linux can ship a working open source compute stack.

The one thing that is missing is Fedora Linux doesn't yet offer a good selection of appropriately licensed models as part of the rpm package distribution. I needed to go to Hugging Face and navigate the complexity of choice there. That's a little rough as a starting point. If we as a project can figure out some good, reasonable, models that we can distribute for local hardware inference that would be a good next step in order to get to a future where we can help simplify things for users. The licensing landscape for the model choices in Hugging Face is.. daunting. And I consider myself well versed as a layperson about the licensing difficulties we face as distributors and redistributors. For now I've downloaded some models and I'm gonna probably write up a comparison among them as part of this dispatch series. Are there Hugging Face models that could be useful and could be redistributed to form the basis of an opinionated Fedora Linux lab installable? I don't know yet.

What's next for me?

I'm looking into agent frameworks so that I can build agents that can run locally. I'm very partial to golang because I don't want to get bogged down in the complexity of python runtime dependencies. Having spent some quality time working with golang in previous jobs, I like the golang src module model quite a lot. About 3 careers ago, I used python heavily as an academic. But now that I've experienced golang, I want to lean-in as much as I can there, even if it means letting go of python as a my preferred development and prototyping tool for my janky personal projects. Anything I can imagine being containerized now.. I'm going to try to do in golang. And my own little agents are definitely something I want to containerize.

Subscribe now

14 Oct 2026 2:07pm GMT

Theme

Experience

There are only so many hours that one could rest for, so, of course, calling it a day early on the previous day led me to wake up early on 26th September 2026. I knew that waking up at 0600am Indian Standard Time would help me reach the venue four hours later with the swags inventory. Since Samyak Jain had arrived on the night before and was planning on joining me for the next couple of days, one of the first things we did was to take the inventory of Ceramic Branded Coffee Mugs and Round Magnet Pin Combos that we had delivered to his relative's house. Working closely with Rajan Shah, we were able to secure the best location for the Red Hat booth and the best schedules for Fedora Project's community presence. We knew from the beginning that we would very likely be the major draw at the booth since we had engaging activities and enticing swags to keep the booth visitors occupied.

Finishing off the breakfast at around 0800am Indian Standard Time, I finally met Samyak at the reception area when he was just returning from the temple. Luckily enough, he had already taken care of having the swag inventories delivered to SRS Springs And Spa Hotel and, alongside that, he had also gone ahead with ordering some stationery after consulting with me. As we did not necessarily have a talk or discussion planned for that day, we wanted to be sure that we had everything we needed for a successful community booth representation. One could not stress just how important supplies like cellophane tapes, marker pens, plastic scissors, thumb tacks, etc., could be in times like these, not just to us Fedora Project folks but also to the neighbouring communities sharing the booth with us, like Ansible, PyTorch, Tekton, Virtualization, and Containers, for the next couple of days of the event.

I was not happy with the incomplete breakfast on that morning, but I did not have the luxury of expressing my dissent at the time. Making do with Boiled Idli and Coconut Chutney, paired with some Onion Pakodas and Hot Tea, I joined Samyak at the hotel reception at around 0930am Indian Standard Time. With the delayed delivery of the swag inventory eating up most of our time, we decided to skip the preliminary accounting and instead haul the entire inventory on our Uber ride to the event venue, NIMHANS Convention Center Bengaluru. Thankfully, Rajan's cohort was able to reach the venue earlier to help set things up amidst the early event rush hours, where we were going to dive right in after some time. Thinking on our feet allowed us to prevent any further delays in reaching the event venue and to take advantage of the first period of the flagship hallway track experience.

With the help of the concierge, we loaded up the heavy units onto the back of our Uber ride, and in the next fifteen to twenty minutes, we found ourselves arriving at the NIMHANS Convention Center Bengaluru. Samyak and I took turns lugging the heavy boxes, weighing 30-40 kg, from the parking area to the registration desk, where we checked ourselves in. Thankfully, our booth was located on the ground floor, right near the entrance, which not only meant that we did not have to play porters for long, but also ensured us the maximum footfall. It was crazy to think just how occupied the venue was, judging by the fact that it had paid registration. With crowd densities comparable to those of free events like FOSDEM etc., this was an expression of just how enthusiastic Indians and people from adjacent regions were about free and open-source software and the folks who maintain it.

Getting to the Red Hat Community Booth was half the struggle - beyond which Samyak and I had to play it by ear to make it behind the already packed booth space. Samyak slowly made his way to the back of the community booth first, while I began unpacking our swag inventory on the desk. With him designing the poster for our community booth interaction activities using generative tooling, it helped us immensely in ensuring that we were able to make meaningful chats with our community of users and contributors at IndiaFOSS 2026 in our period. After a swift catch-up with the likes of Rajan, Deepesh Nair, Shivraj Patil, Veer Kumar Patil, and Gaurav Kamathe, I arranged the metallic Fedora Project-branded round magnet pin combos on the desk at around 1100am Indian Standard Time, which only led to the big crowd at the Red Hat Community Booth grow a whole lot more.

Both Samyak and I knew that we had to leverage the visitor footfall that we drew as the local Fedora Project ambassadors to channel visitors to our FOSS projects. As we were already at our capacity for handling visitors, we deferred handing out the rarer swags, such as Wooden Branded Pop Sockets and Ceramic Branded Coffee Mugs, until later, when the visitor crowd became manageable. Of course, that was a good problem to have, as not only Fedora Project but also the sister community projects could use the attention that we were bringing to the Red Hat Community Booth. Armed with the comparative study between Fedora Linux and other related GNU/Linux distributions, we helped the booth visitors understand the differences. We wanted to ensure that they had the knowledge before deciding on the one that they would want to settle on, instead of incessantly singing the praises of our own.

In the constantly fast-moving world of artificial intelligence, most booth visitors appreciated how Fedora Linux provided them with a curated collection of recent updates for the software applications they used. That, in turn, empowered them to architect solutions for the people of today and the future, instead of waiting much later for them. Being the general-purpose Linux distribution that Fedora Linux was, its appeal was universal among those people who wanted a middle-ground GNU/Linux distribution that was both stable and feature-rich. To our pleasant surprise, we met folks at the booth who learned about Fedora Project while using GNU/Linux distributions such as Bazzite and Ultramarine Linux. Among those questions, we also fielded misconceptions on the figurative death of CentOS Linux and misinformation around Red Hat Enterprise Linux becoming closed source.

Taking one unit of the Ceramic Branded Coffee Mugs at a time to keep the booth conversations going, we were surely able to draw visitors into an interactive task for which Samyak had created the poster. Being this close to our community of users and contributors at an in-person event allowed us to have a unique approach towards gathering feedback. While our questions were subjective in nature and we strictly made a point of not collecting personally identifiable info, we were curious about how this feedback could help shape the future of Fedora Linux. I got to meet various people from both technical and managerial backgrounds who had thoughts on an ideal Linux distribution. As a gesture of thanks, we handed out the limited-edition swag units, all while introducing some friendly competition every now and then whenever a group appeared to keep things lively at our community booth.

In hindsight, the change in our approach towards engaging visitors, from a more passive Google Form during DevConf.IN 2026 to a more active human interview at IndiaFOSS 2026, felt well-guided. While being joined by Sudhir Dharanendraiah, the PyTorch representative, I also got to catch up with him after having met him about six months back. Amidst engaging with the booth visitors, Samyak and I did not realize how we ended up spending most of our time at our community booth itself, even when the designated duty was for the first two hours alone. That was, of course, not a problem; as Rajan mentioned, it was extremely appreciated that we were going above and beyond in steering the crowd of nearby attendees at the venue entrance towards our community booth. The two of us did find ourselves at our energy's limits as we temporarily wrapped things up around the lunchtime.

After a brief run-in with some familiar faces from the Debian Project, namely Ananthu CV and Abhijit PA, and also with some FOSSUnited organizers who came to us for sponsor feedback, we left for the food place. Getting visibly frustrated by the long queue at the serving area, we briefly considered heading out for lunch, only for us to realize later that there were few good places nearby. The closest one was a couple of kilometers away, and we would not be able to return in time if we were to travel there through Bengaluru's traffic. Turning back to the event lunch by around 0130pm Indian Standard Time, we found that the previously huge queue had subsided greatly by then. With no place to sit and eat, we resorted to refuelling ourselves with some Boiled Rice, Mattar Paneer, Mixed Vegetable, Chilled Raita, Warm Chapatis, and Gulab Jamun while standing near the rear exit of the venue.

Finishing off our food by around 0200pm Indian Standard Time, we still had half an hour more to kill before heading back to the community booth. We used this time to explore other community booths that were located at the event venue. It would have been a waste not to interact with FOSS friends from various teams just because we were too occupied representing our own. There was learning to be had, not just from the enthusiastic visitors coming to our booth, but also from being one of the visitors to the neighbouring booths. That led me to having a lively chat with the folks representing F-Droid about the recent unfair restrictions introduced by Google on certified Android handheld devices. Leaving Samyak in a quiet hall on the first floor to recover, I continued by myself to explore the booths on the other side of the event venue, which were mostly about the embedded electronics.

With its majority portion conveniently hidden behind thick vegetation, NIMHANS Convention Center Bengaluru was a deceptively huge location. I could not have guessed that there was an entire second part of the floor being shared by the Red Hat Community Booth with others because of the impressive floor planning. In the hardware section, the couple of event booths that caught my attention exhibited low-profile, manually crafted ergonomic mechanical keyboards and various useful ESP32-based trinkets. It was quite the coincidence to run into another FOSS friend whom we met during FOSSAsia 2026, Anuvrat Parashar, with whom I caught up and shared a few clicks. At around 0245pm Indian Standard Time, it was time for me to head back to our community booth for the second half of the Fedora Project representation duty and connect with Samyak for his assistance while returning.

Manoj Kumar Gupta, who was representing the virtualization team, remarked on just how influential Fedora Project's presence was at the community booth, all while reflecting on how the activity nearly died down in both Samyak's and my absence. He was right, though, as swag collectibles can be conversation starters for a bunch of people who might arrive at the event booth for collectible trinkets but also stay back for the interesting conversations that we have to offer. With our swag units displayed on the booth desk again and Samyak started the discussions, I got the FOSSUnited tees for us that Rajan had kept aside for the event sponsors. Seeking coffee with Sudhir at around 0400pm Indian Standard Time led us to have a great catch-up with him at the dining area. On heading back, Veer Kumar even graciously offered his specialized audio recording device for our interviews.

Being super occupied at the community booth, I could not attend Rajan's bite at the 2026 FOSSUnited GB Elections: Meet The Candidates Session. For someone who had been supporting Fedora Project's local presence in India as well as in the APAC region, it felt important to support him. Anyway, we started packing up the community booth at around 0515pm Indian Standard Time after attending to the booth visitors who had missed us during lunchtime. Thanks to Shivraj's query to the FOSSUnited personnel, we did not have to return to the hotel with all the booth supplies, as we could securely store them at the booth area. To ensure that Samyak had what he needed to organize the Fedora Linux 45 Release Party at a local university in the following month, I ensured that I passed on the limited swag units to him so that they could be returned before being used up on the next day.

For an in-person FOSS conference where Fedora Project could not timely secure a separate community booth, I scarcely imagined just how much attention we would eventually end up getting. With the folks from Red Hat being mutually supportive, since even they utilized Fedora Linux-powered Corporate Standard Builds on their work devices, this had been an experience like none other. Nine times out of ten, when Fedora Project was a conversation starter at our community booth, it was endearing to observe how most folks stayed back to learn more about projects like Shipwright, PyTorch, Tekton, Confidential Computing, and Ansible, etc. With our evening plans still being tentative at the time, our little Red Hat group decided to have some coffee on our way out. At around 0530pm Indian Standard Time, Samyak was finally able to book a returning Uber ride to take us back to the hotel.

The Bengaluru traffic situation only drifted from bad to worse as the sun started going down, so it took us a while to make it to the other side of the road where the auto-rickshaw had been waiting for us. We headed out once more on Deepesh's invitation to Brooks And Bonds Brewery at around 0730pm Indian Standard Time. Even though I did not hear back from Samyak for a little while when I had booked an Uber ride for us, he was swiftly available in the lobby area after a couple of hours of resting. Moving through the evening Bengaluru traffic, we were able to make it just in time to see Rajan, Shivraj, Veer Kumar, Gaurav, and Deepesh on their way upstairs in the building's elevator. For a dining experience that had been overbooked on that weekend evening, Deepesh definitely made the right call in booking us a large table well in advance to ensure that we were able to secure one.

It was a lovely evening catching up with the folks over some nice drinks and tasty bites. Partitioning the dining table to place ourselves based on dietary preferences, we stuck around to see if we could get ourselves a table outdoors. With Samyak briefly checking with one of their attendees and returning empty-handed, we stuck around with the table that we had. Looking back on it, I would not have necessarily advised an outing like this in the evening if one was to wake up early the next day. I still found myself hanging back with the folks till 0130am Indian Standard Time. As luck would have had it, it was down to me again to set things up at the Red Hat Community Booth the next morning. I was uncertain about the task being fulfilled, so I wasted no time in falling asleep and recouping energy once Samyak and I were finally able to get an Uber ride back to the hotel at 0230am Indian Standard Time.

13 Oct 2026 6:30pm GMT

13 Oct 2026 6:14pm GMT

13 Oct 2026 3:14pm GMT

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.

13 Oct 2026 11:06am GMT

Across the Fedora project this week, the primary focus is stabilizing the upcoming Fedora 45 release, which has officially entered its Final Freeze. Teams including Release Engineering, Quality, and various desktop and architecture groups are actively triaging blocker bugs, testing deliverables, and locking down infrastructure changes. Beyond the immediate release, a major collaborative focus is the newly named "Atomic Fusion" initiative, a strategic effort uniting the Atomic, CoreOS, IoT, and Hummingbird groups to design a unified, Konflux-built base image that minimizes attack surfaces by excluding tools like cloudinit and ignition. On the operational front, groups are heavily engaged in evaluating workflow tooling, marked by widespread assessments of a Bugzilla-to-Forgejo migration-which FESCo is currently pushing back against-and the rollout of LLM-powered community reporting tools, which prompted teams like Workstation and CoreOS to establish strict privacy and human-review boundaries. Finally, repository health remains a continuous cross-team priority, with FESCo, the Rust community, and NeuroFedora actively addressing orphaned packages and non-responsive maintainers to prevent downstream dependency breakages.

Announcements

On the development and infrastructure front, Fedora 45 has officially entered its final freeze, and an impact assessment for removing inactive packagers for the F45 release cycle lists potentially orphaned packages that currently need new maintainers. Infrastructure updates include detailed progress and plans for s390x improvements to address resource constraints, necessitating a planned s390x reboot. For QA and testing contributors, a Podman Test Week (also covered in a detailed Fedora Magazine article) invites help testing the Rust-based conmon v3, while community members continue to share advice on BTRFS system recovery methods.

Council

The Council held a bi-weekly meeting to discuss the F45 Final Freeze, finalize the new Decision Support Process, and begin brainstorming for Flock to Fedora 2027 Call for Proposals (CfP) themes. The Fedora Forge Usage Policy and Fedora Docs 2025 Initiative were formally closed following their approvals and updates, while @jflory7 was officially off-boarded from the Council following the end of his term as Fedora Community Architect.

New proposals were introduced regarding internal processes, including a non-binding "Sense of Council" vote process and making the Council Matrix channel publicly logged. A Bootable Image Unification Meeting also took place, where the team discussed Architecture Design Records (ADRs) and agreed on the project name "Atomic Fusion".

Decisions

• The Council finalized the conflict of interest discussions into a new Decision Support Process, deciding that the Fedora Operations Architect (FOA) will be the default owner to triage and action these requests.
• The Fedora Forge usage policy was officially approved and a request was made to add it to the official documentation.
• The Council voted to review and provide feedback on the Flock 2027 CfP themes via ticket comments, aiming for a usable draft by October 21, 2026.
• The external fundraising / Open Collective exploration ticket was closed to restart the effort properly with fresh, public discussion alongside the Mindshare Committee.

Contribution opportunities

• The Fedora Docs 2025 Initiative is requesting a six-month extension and is actively looking for a new executive sponsor to take over the role.
• Contributors interested in the "Atomic Fusion" Bootable Image Unification effort are invited to participate in consolidating the umbrella ADRs by joining the Bootable Image Unification Matrix channel.

Learn more about the Council team.

FESCo

FESCo addressed several critical governance, security, and infrastructure topics this week. The committee continued pushing back on the proposed migration from Bugzilla to Forgejo due to major feature regressions (e.g., cross-repo searches, bug relationships) and discussed exploring a self-hosted or consultant-supported Bugzilla instance instead. Additionally, FESCo processed multiple non-responsive maintainer tickets, notably prioritizing the retirement of vulnerable NetworkManager VPN plugins (NetworkManager-vpnc and NetworkManager-fortisslvpn) going back to Fedora 43. This obsoletion will impact existing users but was deemed an unavoidable security measure to prevent privilege escalation.

Other highlights include the nomination of a new FESCo member (maxamillion) to fill a vacant seat, progressing the change to use Sequoia (%openpgpverify) for post-quantum cryptography, and reaffirming strict boundaries for provenpackagers regarding mass package changes.

Decisions

• Retired and obsoleted NetworkManager-vpnc and NetworkManager-fortisslvpn across Fedora releases down to F43 due to unpatched privilege escalation vulnerabilities. (Ticket #3681)
• Elected to mark fedora-third-party updates as a blocker for Fedora Linux 45. (Meeting Log, Ticket #3682)
• Reaffirmed the provenpackager policy, specifically that provenpackagers must not perform mass cleanups or changes-such as converting to %autorelease or %autochangelog-without explicit maintainer permission. (Ticket #3687)
• Nominated maxamillion to fill the vacant FESCo seat left by duffy's resignation, which he accepted. (Ticket #3689)
• Processed non-responsive maintainer tickets for lkundrak, prarit, and gui1ty, resulting in the transfer to new volunteers or mass-orphaning of their respective packages. (Ticket #3681, Ticket #3665, Ticket #3678)

Learn more about the FESCo team.

Packaging Committee

This week, the Packaging Committee focused on two major themes: simplifying RPM snapshot versioning and updating Emacs packaging guidelines. Triggered by a recent versioning error in the bluez package that broke upgrade paths and caused openQA failures, the committee is heavily discussing a move to standardize snapshot versioning to a single, simpler format (<number>.<revision>) to prevent future mistakes (Issue #1570, Issue #1578).

Additionally, the group is modernizing its Emacs guidelines. This includes a new Work-in-Progress proposal to introduce RPM macros and dependency generators that natively support Emacs' built-in package management system, alongside finalized updates to existing Emacs packaging rules.

Decisions

• The pure GTK Emacs build is now explicitly packaged under the name emacs-pgtk (Issue #1575).
• The packaging guidelines were updated to clarify that Emacs 'compilation' refers strictly to byte compilation, distinguishing it from newer native compilation features (Issue #1574).

Learn more about the Packaging Committee team.

Mindshare

During the week of October 5 to October 11, 2026, the Mindshare committee actively cleared a backlog of event funding and swag requests while taking concrete steps to improve its own administrative efficiency. The committee successfully formalized a weekly meeting cadence-alternating between text and video formats-to curb previous delays in ticket resolutions.

Alongside standard event approvals, strategic discussions took place regarding the modernization of Fedora's physical event presence. This included plans to replace aging US and EU event boxes with new Pelican Air cases, the creation of a dedicated event box for India, and the production of localized tablecloths for EMEA events. Additionally, in response to persistently vacant seats on the committee, members proposed a structural change to allow rotating representation from active teams like Fedora Docs and Magazine, rather than static appointments.

Decisions

• Decided that the Fedora Design team will no longer supply custom artwork for event badges; event organizers must now design their own badges and submit them for Mindshare approval with a 30-day lead time (Ticket #145).
• Adopted a new weekly meeting cadence, alternating between text and video formats, to improve the committee's responsiveness to requests (Ticket #135).
• Approved producing an EMEA-specific event tablecloth first before expanding regional physical assets to APAC (Ticket #119).
• Maintained the current shared-responsibility model for Fedora's representation in the Digital Public Goods Alliance (Ticket #152).
• Approved regional swag and travel budgets for Texas Linux Fest 2026 (Ticket #148), LinuxDays 2026 (Ticket #149), IndiaFOSS 2026 (Ticket #147), and a Polish technical school (Ticket #138).

Contribution opportunities

• Provide feedback on the proposal to reconsider Mindshare Committee representation by rotating seats based on team activity and needs, potentially reallocating vacant CommOps or Marketing seats to the Fedora Docs or Magazine teams (Ticket #154, Ticket #145).
• Weigh in on the idea to create a DIY printable "Ask me about Fedora" t-shirt design (complete with a QR code) for community members to wear at conferences where Fedora lacks an official booth (Ticket #99).
• Mindshare Committee members are requested to pledge their timely availability to address recent delays in ticket voting and event curation (Ticket #153).

Learn more about the Mindshare team.

Fedora Join

This week, the Fedora Join group's primary focus was on addressing technical debt and improving the visibility of Fedora's web applications. Efforts are underway to update the outdated apps.fedoraproject.org directory. This exploratory project involves auditing existing applications, identifying unlisted infrastructure tools, and upgrading the web app's underlying Python software stack.

A community member has recently been assigned to take on this task as a "good first issue." The work will require collaboration with the broader Fedora Infrastructure team to ensure that the web directory accurately reflects the current state of active Fedora services.

Contribution opportunities

• The task to update apps.fedoraproject.org was identified as an excellent "good first issue." Although a community member has begun the initial exploratory work, the effort requires reviewing current infrastructure, discovering missing tools, and potentially upgrading the codebase to support modern software versions, which may offer further avenues for collaboration.

Learn more about the Fedora Join team.

Workstation / GNOME

The Workstation / GNOME group focused on preparations for the Fedora 45 release, evaluating blocker bugs and freeze exceptions as the Final Freeze begins. A major technical priority was fixing integration issues for the new oo7-daemon (which replaces gnome-keyring-daemon), specifically ensuring its portal component is correctly installed on Silverblue and GNOME systems. Additionally, developers are actively scripting the automation of appstream-data generation to prevent GNOME Software and KDE Discover metadata from becoming outdated between releases.

In other discussions, the Working Group addressed third-party software requests and clarified questions about dependencies. The group also provided feedback on these weekly reports, requesting that human review remain in place to filter out irrelevant or personal information before publishing chat summaries.

Decisions

• The Working Group rejected a proposal to include the proprietary, subscription-based LiveFaceSwap Desktop application in Fedora Workstation's third-party software discovery (Issue #530).
• To resolve missing dependencies during the transition to oo7-daemon, xdg-desktop-portal-gnome will now explicitly require oo7-portal to ensure it is installed by default on GNOME and Silverblue variants (Issue #506).
• The Working Group requested that human review of community posts and Matrix chat logs be required before including them in these automated weekly summaries, ensuring personal or irrelevant details are not broadcast (Issue #527).

Contribution opportunities

• Vote on Fedora 45 Blockers: Community members are encouraged to vote on proposed blockers and freeze exceptions for Fedora 45 in the blockerbugs app before review meetings. Voting in advance helps shorten the meetings (Meeting Announcement).
• AppStream Data Automation: There is ongoing work to automate the weekly generation of appstream-data. Contributors interested in packaging automation or verifying metadata diffs between Fedora versions can follow or assist in the progress (Issue #507).

Learn more about the Workstation / GNOME team.

KDE

The KDE group is preparing for the upcoming releases of KDE Plasma 6.8.0 and KDE Apps (Gear) 26.08.2. Due to the Fedora 45 final freeze, these major updates have already been pushed to Rawhide. For Fedora 44 and 45 users, the updates will be temporarily combined and made available via a COPR repository until the freeze is lifted and Fedora 45 is officially released.

In other news, the team is actively working on pulling the Union theme into Plasma Workspace, and preparations are underway for the Fedora 45 Blocker Review Meeting to finalize the upcoming OS release.

Decisions

• KDE Plasma 6.8.0 and KDE Apps 26.08.2 updates will be delayed for Fedora 44 and 45 until the F45 final freeze concludes; they will be provided via a COPR repository in the interim.
• The kgamma and kcm_wacomtablet packages will no longer receive updates and will be retired once Plasma 6.8 is released.
• Due to a libplasma soname bump in the Plasma 6.8 update, several dependent packages (including merkuro, kweather, kclock, kalgebra, kcm-fcitx5, kup-backup, and applet-window-buttons) will be rebuilt.
• The Union theme will be added to the KDE deliverables, starting with a recently rebased pull request for plasma-workspace.

Contribution opportunities

• Contributors and upstream community members are needed to help plan and participate in the KDE Plasma 6.8.0 Test Day, including exploring testing methods for Kinoite.
• Community members are encouraged to review and vote on F45 blocker bugs prior to the Fedora 45 Blocker Review Meetings using the blockerbugs app.

Learn more about the KDE team.

Server

The Server working group focused this week on F45 Beta release testing and advancing their Server Ansible support project. In F45 testing, initial-setup issues with the KVM image were successfully resolved, though some partition type issues with Kiwi persist. The group also briefly discussed aligning with the wider Fedora ecosystem by exploring a Borg-based backup solution, as backup coverage for F44 Server is currently lacking.

On the Ansible front, work is nearing completion to package the Server Ansible collection as an RPM, which will soon be released on Copr. Contributors identified idempotency and permission issues in the postinstall role, leading to plans to set up a molecule testing harness to test idempotence continuously. Finally, an announcement was shared on the mailing list regarding the upcoming F45 Blocker Review meeting for finalizing the release.

Decisions

• The group decided to hold off on immediately fixing the Kiwi partition type issue, as it is non-blocking and can be corrected during post-installation.
• Agreed to provision a dedicated VM for a molecule testing harness to ensure idempotence across the Ansible collection.

Contribution opportunities

• Contributors are asked to keep an eye on the F45 Beta testing tickets and claim tasks by leaving a comment.
• The working group is seeking help to draft the first versions of user documentation for their new Ansible support.
• There is a known gap in backup strategies and coverage for F44 Server; contributors familiar with backup tools (like Borg) have an opportunity to help shape Server backup documentation and defaults.

Learn more about the Server team.

Infrastructure

The Infrastructure group entered the Fedora 45 Final Infrastructure Freeze on October 6th, locking down system changes until after the release. Operations this week involved handling s390x hypervisor memory issues, replacing a failing RAID controller on a Copr builder host, and resolving an EPEL 10 repository access issue caused by version differences between RHEL and CentOS Stream. Additionally, discussions continued on migrating from Bugzilla to Forgejo, tracking AWS resource costs, and optimizing LLM code reviews on Forgejo.

The team welcomed several new contributors this week and processed multiple new tracking groups in FAS (including Fedora Java Lounge, dpdk, Regolith, and Free Explorers) alongside updates to mailing list ownerships and documentation fixes.

Decisions

• The Fedora 45 Final Infrastructure Freeze is in effect until at least October 20th. Frozen hosts should have no changes made to them without a sign-off from at least 2 sysadmin-main or rel-eng members.
• For CentOS 10 containers failing to install EPEL packages, a temporary workaround has been provided (dnf -y install epel-release && dnf -y upgrade epel-release) until RHEL 10.3 is released in November and the main epel-release-latest-10 symlink can be safely updated.
• Due to repeatedly failing disks on vmhost-p09-copr03, the host will be swapped out for a spare IAD2 Power9 host rather than reinstalling the existing faulty hardware.
• The Bugzilla to Forgejo migration assessment is underway; the team notes significant required workflow adaptations (e.g., losing global issue tracking and rewriting automated scripts like bugzilla2fedmsg and the-new-hotness).
• Documentation sources for the Fedora Design Suite Wiki are migrating directly to Forgejo instead of relying on a MediaWiki OIDC integration.

Contribution opportunities

• Review untagged AWS resources older than 24 hours. Owners must add the FedoraGroup tag to prevent automated deletion.
• Help is requested to create a playbook to automate the creation of tracking groups, which requires defining variables for description/display names and setting up FAS group configurations.
• The team welcomes newcomers! Interested contributors are encouraged to read the Infrastructure Join Guide and start with good-first-issues or small ticket requests in #noc:fedoraproject.org.

Learn more about the Infrastructure team.

Release Engineering

This week, the Release Engineering team successfully initiated the Fedora 45 Final Freeze. The team managed several critical build and infrastructure issues, including fixing a permissions bug that caused 403 errors on PXE boot images, resolving an AWS IAM role policy issue that broke Fedora CoreOS uploads, and mitigating an XML parsing failure on Koji builders triggered by a Python 3.14 update.

Looking forward, discussions and preparations have begun for a major system-wide change in Fedora 46 to switch to the RPMv6 package format. The team plans to test the rollout conservatively in a side-tag using a few select packages before considering broader implementation.

Decisions

• Fedora 45 officially entered its Final Freeze phase on October 6 (Issue #13544).
• Bug 2540692 (Cannot authenticate to secure wifi during gnome-initial-setup) was accepted as a Fedora 45 Final Blocker during the October 5 Blocker Review meeting.
• Bug 2545485 (Storage editor ignores BTRFS subvolumes under specific naming conditions) was rejected as a Final Blocker but accepted as a Freeze Exception during the October 5 Blocker Review meeting.
• The Fedora-ELN-NetworkInstaller package was created in the eln tag so Fedora ELN can transition to using image-builder for building artifacts (Issue #13547).

Contribution opportunities

• Community members are invited to review and provide feedback on the Fedora 46 change proposal to switch to the RPMv6 package format (wiki proposal here).
• Contributors can help streamline release efforts by voting on proposed blocker and freeze exception bugs prior to the upcoming Fedora 45 Blocker Review Meetings.

Learn more about the Release Engineering team.

Quality

The Quality team is highly focused on the final stages of the Fedora 45 release, which has officially entered the Final Freeze. Release validation is currently in progress, with strong test coverage and a relatively short blocker list. The team has been actively testing major new features, including kmscon userspace consoles and imagebuilder-built installer images, and recently discovered and fixed a longstanding bug affecting missing console keyboard layouts.

Test Days remain a major focus, with the Anaconda and CoreOS events concluding, and the Podman Conmon-v3 Test Days scheduled for mid-October. The team also conducted their weekly blocker review meeting, discussed streamlining predictable release chores by adding them to the automatic blockers list, and published the Q3 Heroes of Fedora Quality statistics to highlight and thank top community contributors.

Decisions

• It was generally agreed on the mailing list to add 'updates-testing repository still being enabled' and 'fedora-release package having a release number lower than 1' to the automatic Final release blockers list to save time during future blocker reviews.
• Bug 2540692 (Cannot authenticate to secure wifi during gnome-initial-setup) was officially accepted as a Fedora 45 Final Blocker.
• Bug 2545485 (Storage editor ignores BTRFS subvolume(s) if partition has the same filesystem label) was rejected as a Final Blocker but accepted as a Final Freeze Exception.
• Decision on Bug 2544626 (aarch Server DVD image install fails on RPi4 without network connection) was punted for a future meeting due to a lack of clear consensus.
• To resolve ongoing CI frustrations in dist-git PRs, rpmlint spelling checks will be downgraded to output warnings rather than errors (Issue #591).

Contribution opportunities

• Testers are needed for the upcoming Podman Conmon-v3 Test Days from 2026-10-12 to 2026-10-18.
• Contributors are encouraged to help improve the Heroes of Fedora Quality tools and workflows by automating the data collection and output generation for tester statistics.
• The team is seeking help to automate the mediakit checksums test case, which is currently performed entirely manually.
• Anyone with access to Beaker hardware is invited to help test F45 installations on bare metal and assist in writing a short guide for reserving machines.

Learn more about the Quality team.

Websites and Apps

The Websites and Apps team updated the Fedora download pages to visually highlight release-blocking deliverables with a star, clarifying for end users which images are fully tested by the Fedora Quality team versus those that are not. In the Fedora Websites Matrix room, the team discussed improving overall page load speeds by converting images to WebP format, bundling fonts, and downscaling new screenshots to 1360x768.

In the Fedora Apps Matrix room, a new build of Anitya was deployed to the staging environment for testing ahead of an upcoming release. The team also diagnosed a temporary rate-limiting issue with crates.io on release-monitoring, and clarified user confusion around the Badges admin interface, explaining that the UI remains visible but permission checks are safely performed retroactively when actions are attempted. Lastly, a forum discussion was started regarding the verbosity and excessive use of emojis in LLM-generated code reviews on Forgejo.

Decisions

• Release-blocking deliverables on the Fedora download pages are now explicitly marked with a star to distinguish them from non-blocking images that lack guaranteed testing.
• Secondary navigation bar logos on Fedora websites were updated to monochrome SVGs to improve visual consistency and reduce bandwidth.
• New website screenshots for the upcoming Fedora 45 release will be scaled down to a 1360x768 resolution to help optimize page load times.

Contribution opportunities

• Help is requested to update screenshots for Fedora 45 across all Editions, Spins, and Atomic Desktops.
• There is an open opportunity to remove outdated references to Zanata in the event CMS templates and replace them with references to Fedora Weblate.
• Contributors interested in website optimization can help investigate improving page load times by converting large images to the WebP format or bundling fonts.
• There is a long-standing wishlist item to create reusable event-specific page templates for major events (like FOSDEM, SCaLE, and DevConf), which currently rely on the Fedora Wiki.

Learn more about the Websites and Apps team.

Design

The Fedora Design team delivered promotional graphics and visual assets for the upcoming F45 Virtual Release Party, including social media banners and streaming templates. The team also concluded an investigation into Bugzilla workflow dependencies, confirming they exclusively use Forgejo and will be unaffected by Bugzilla's upcoming retirement. Additionally, a pull request was submitted to add CSS branding for the new WebUI-based installer to the fedora-logos package.

In their weekly meeting, the team reviewed CDUX logo mockups and managed their backlog by closing stale tickets. To improve workflows, they are restructuring their ticket queues to separate feature improvements from operational tasks. Ongoing open tasks include creating a high-resolution logo for GDM to fix fractional scaling blurriness, designing the F46 beta wallpapers, and crafting an avatar for the Matrix moderation bot.

Decisions

• Bugzilla Sunset Assessment: The team determined that the Bugzilla retirement will not impact their workflow, as they exclusively use Forgejo. No further migration planning is required for the Design group.
• Ticket Queue Restructuring: The group decided to establish a separation between standard operational tasks and feature improvements, planning to use a feature/improvements label.
• CDUX Logo Update: The team agreed to replace the fountain pen with a paintbrush in mockup 1C of the CDUX logo.

Contribution opportunities

• Design event-kit hex stickers for CentOS and EPEL, as requested in the Matrix chat.
• Provide a high-resolution (at least 600px width) SVG-derived Fedora logo to fix fractional scaling blurriness in the GDM greeter out-of-the-box experience (Issue #87).
• Create a new avatar for the Matrix Moderation bot (Issue #68).
• Help design the "Beta" wallpaper for Fedora 46 ahead of the mid-November deadline (Issue #77).
• Conduct initial user experience research on existing Fedora remix sites and Jekyll themes for Project Resistor (Issue #84).

Learn more about the Design team.

Docs

This week, the Docs team focused heavily on restructuring their Antora site architecture to allow for flexible module inclusion across different Special Interest Groups (SIGs). They decided to merge components under the ROOT namespace to shorten URLs and simplify maintenance, a massive change that will be tested incrementally on a newly configured staging instance. Furthermore, the team made progress integrating new AI/ML SIG and Security team documentation into the main user documentation structure.

Additionally, the team prepared the Beginner's Guide for the upcoming Fedora 45 release, resolved accessibility issues with image descriptions, and advanced collaborative writing efforts with a live CryptPad instance running in CommuniShift.

Decisions

• To accommodate cross-repository module inclusion (such as the new Security SIG user docs), all Docs repositories will transition to using ROOT as their antora.yml component name, which drops component names from the URLs altogether. This will be implemented and tested on a staging instance first, as discussed in Ticket #66 and the Oct 6 Meeting.
• The Security team's new user-facing documentation module will temporarily be included at the Fedora Linux latest index until the repository grows large enough to warrant its own dedicated space (Ticket #65).
• The obsolete prod branch in the builder repository will be renamed to main, pending successful testing on the staging Forge (Ticket #61).

Contribution opportunities

• Contributors are invited to provide feedback and suggest missing commands for a new WIP Git cheat sheet for writers.
• Reviewers are requested to proofread the Vorta backup section in the Beginner's Guide for typos before the Fedora 45 release.
• Community members can test the experimental Cryptpad instance in CommuniShift to evaluate its suitability for collaborative documentation drafting.

Learn more about the Docs team.

Legal

This week, the Legal group discussed the licensing of several projects and revisited existing policies. A significant portion of the conversation revolved around Fedora's policy on the CC0 license (also discussed here), which is currently restricted for software due to its explicit lack of patent grants. Despite user arguments to reconsider based on the license's "quiet enjoyment" waiver, legal experts maintained that the ban remains appropriate and aligns with both the license's original drafting history and current Free Software Foundation guidance.

Other discussions addressed specific packaging efforts. The Slint UI Framework was reviewed, and it was clarified that its GPL-3.0-only option is acceptable for packaging despite its broader dual-licensing and inbound MIT-0 contribution policy. Finally, a review of the koneko package determined that copyrighted third-party sprites must be removed at the source tarball stage to comply with distribution guidelines.

Decisions

• The koneko package's source tarball must be modified to remove copyrighted Cardcaptor Sakura artwork before it can be packaged.
• The Slint UI Framework is acceptable for packaging in Fedora under its GPL-3.0-only license option.

Learn more about the Legal team.

EPEL

This week, the EPEL team navigated tooling updates for the EPEL 10 transition, noting a bug in fedrq and a new mock release that simplifies repository configurations. In EPEL 9, Qt6 is being updated to version 6.10.3, which requires rebuilding a handful of dependent packages. Additionally, maintainers announced the retirement of several packages, and work continues on creating Koschei playbooks for minor End-of-Life and mass branching processes.

Decisions

• rust-libz-rs-sys is being retired from EPEL 9 and EPEL 10 by its maintainer, as it has been a leaf package for some time and is no longer useful for general development.
• singularity-ce will be retired from EPEL at the start of November, following the upstream project reaching End of Life / End of Engineering.
• python-sphinxcontrib-apidoc is being retired from EPEL 8 and EPEL 9 because it has been uninstallable. Maintenance will continue for EPEL 10, with a community member stepping up to help manage it.

Contribution opportunities

• Help is needed to fix obs-studio build failures against the new Qt 6.10.3 update in EPEL 9. The maintainer is open to suggestions and has provided a Copr repository for testing installs and builds.

Learn more about the EPEL team.

ELN

During the October 6, 2026 meeting, the ELN SIG discussed the transition to building boot.iso with image-builder. Minor OpenQA failures were noted in Rawhide, prompting the team to postpone the switch for a week to allow the changes to stabilize before being pulled into RHEL and CentOS Stream. The group also reviewed ELN Extras build failures (FTBFS), noting ongoing fixes for OpenSSL 4.0 compatibility (the_foundation and libesmtp) and resolving KDE issues caused by missed rebuilds. Finally, the team addressed Bodhi updates getting stuck due to planned outages and agreed on a procedural change to prevent this in the future.

Decisions

• The team decided to delay the switch to building boot.iso with image-builder until next week to let recent Rawhide changes stabilize (Releng Ticket #13547).
• Infrastructure documentation and procedures will be updated to automatically pause and unpause elnbuildsync (EBS) during future planned outages to prevent updates from becoming stuck (Meeting Log).

Learn more about the ELN team.

Atomic

This week, the Atomic group focused heavily on the unification of Fedora CoreOS and Atomic efforts under the new project name, "Atomic Fusion." The team held their first dedicated video meeting to discuss Architectural Decision Records (ADRs), specifically focusing on a unified base image architecture built with Konflux, which excludes cloudinit and ignition to minimize attack surfaces. They also established standard operating procedures for the project, including a weekly Thursday video meeting cadence, a "Doacracy" work prioritization model, and utilizing a renamed Matrix channel for communication.

In addition to unification planning, several technical issues were addressed for Fedora 45. The group merged a change to use kmscon as the default VT console in F45, resolving dependencies to bring it to bootc base images. A packaging bug causing COSMIC Atomic spin rawhide composes to fail was fixed in the latest compose, and an update was pushed to fix a missing public key error during system upgrades. The team is also actively investigating a boot failure and emergency mode issue affecting users who upgrade on non-BTRFS filesystems.

Decisions

• Fedora 45 will use kmscon as the default VT console for Atomic images (Source).
• The official project name for the CoreOS and Atomic unification effort is "Atomic Fusion" (Source).
• The team will prioritize work using a "Doacracy" model, meaning contributors who step up to do the work will set the immediate task priorities (Source).
• Unification meetings will be held weekly over video on Thursdays, as listed on the Fedocal SIG calendar (Source).
• The old initiative Matrix channel has been officially renamed to serve as the main workspace for unification discussions (Source).

Contribution opportunities

• Help is requested to consolidate the initial Architectural Decision Record (ADR) subdecisions for the unified base image into a single reviewable pull request. Interested contributors should join the Bootable Image Unification channel on Matrix to coordinate (Source).
• Community members are invited to participate in the CoreOS and Atomic Unification effort by joining the newly scheduled weekly video calls on Thursdays and assisting with the migration to the unified architecture.

Learn more about the Atomic team.

CoreOS

The Fedora CoreOS and bootc teams have officially begun merging their efforts, moving unification planning and architecture discussions to a dedicated Thursday video call, while leveraging the regular Wednesday meeting to handle current events, challenges, and tickets for both offerings. As the Fedora 45 Final Freeze is underway, several important fixes have successfully landed, including using kmscon as the default VT console, removing DTBs on aarch64 to save space in the boot partition, and officially declaring the composefs backend stable in bootc 1.17.0.

The community also addressed a slew of hardware and platform-specific pipeline issues this week. Notably, an AWS AMI import pipeline failure caused by a missing IAM role permission was resolved, and Azure Confidential VMs (CVMs) not picking up Ignition custom data was fixed via an upstream Ignition update. Meanwhile, the group agreed to use a build postprocess to patch dracut 111 errors on rawhide rather than continuing to wait on delayed upstream RPM backports.

Decisions

• Decided to unify CoreOS and bootc community meetings and outputs, establishing a regular Thursday video call for architecture and planning.
• Decided to remove Device Tree Blobs (DTBs) on aarch64 builds in Fedora 45 and later to save space in the /boot partition (#2222).
• Decided to manually patch a known failing file in dracut directly during the build postprocess for Fedora \<= 46 instead of waiting on upstream RPM updates (#2206).
• Decided to limit data collection for LLM-powered weekly reports strictly to official meeting logs and GitHub repositories, excluding raw chat conversations due to privacy concerns (#2223).

Contribution opportunities

• Volunteers are needed to help clean up FCOS manifest overrides, which largely involves following up with upstream package maintainers. Interested contributors can reach out in the CoreOS meeting channel.
• Contributors are invited to help write and consolidate Architectural Decision Records (ADRs) for the unified base image architecture. Interested parties should join the Bootable Image Unification channel on Matrix (as noted in the forum discussion).

Learn more about the CoreOS team.

IoT

This week, the IoT group focused on standardizing bootable image architectures and general repository housekeeping. The newly named "Atomic Fusion" project held a kickoff meeting for bootable image unification, proposing an Architectural Decision Record (ADR) that leverages container files and downstream variants while excluding cloudinit and ignition to minimize attack surfaces. They also recommended using Konflux as the standard build system for all Fedora bootable image outputs and systemd system extensions for platform-specific configurations.

In parallel, the team closed several long-standing tickets, highlighting that the Fedora ROS2 testing repository is now officially available in the ROS2 documentation as a result of collaboration with the Robotics SIG. Other closed trackers included updates for the deprecation of the Zezere provisioning tool, resolving Lua script upgrade errors, missing license files in osbuild installers, and initial bootc container builds.

Decisions

• The bootable image unification project was officially named "Atomic Fusion".
• Atomic Fusion's base image will exclude cloudinit and ignition to minimize attack surfaces, manage platform-specific configurations via systemd system extensions, and use Konflux as the standard build system for all Fedora bootable image outputs.
• The Fedora ROS2 testing repository was officially declared available for use in the ROS2 documentation, expanding Fedora's support for robotics and factory automation use cases.

Contribution opportunities

• Contribute to the Atomic Fusion image unification work by reviewing and consolidating Architectural Decision Records (ADRs) in the project's Forgejo repository.
• Join the Bootable Image Unification channel on Matrix to participate in ongoing discussions about unified base image architectures.

Learn more about the IoT team.

ARM

The ARM community was notified of the upcoming Fedora 45 Blocker Review Meeting, scheduled for October 12, 2026, at 16:00 UTC on Matrix. The meeting will focus on evaluating 4 proposed blockers and 7 proposed freeze exceptions for the Final release to determine if they violate any release criteria.

Participants were strongly encouraged to review the bug lists and cast their votes ahead of time using the blockerbugs app, which helps streamline the meeting and reduce its overall duration.

Contribution opportunities

• Review and vote on proposed blocker bugs and freeze exceptions for Fedora 45 prior to the meeting using the blockerbugs app or Pagure tickets.
• Attend the Fedora 45 Blocker Review Meeting on October 12, 2026, at 16:00 UTC via Matrix.

Learn more about the ARM team.

Alternative Images

The Alternative Images group met to discuss the upcoming quarterly image updates, which are targeted for release in roughly two weeks. A major highlight for this quarter's release will be the introduction of the project's first aarch64 raw images, generated using KIWI configuration.

In addition to the upcoming images, the team reported progress on building RISC-V packages for CentOS Stream 10 and processing Qt 6 updates for EPEL9. Testing for these alternative architectures has also improved, as team members noted that transitioning development laptops to Fedora CSB has successfully enabled multi-arch virtualization for local aarch64 and riscv image testing.

Contribution opportunities

• Help is needed to patch or update obs-studio for EPEL9; it is currently failing to build during the Qt 6 updates because GUI-Private was removed in Qt 6.10 (Meeting log).

Learn more about the Alternative Images team.

Hummingbird

The Hummingbird group kicked off its video meeting cadence for the bootable image unification effort, which aims to merge the CoreOS and Atomic Initiatives. During the October 8 meeting, the team reviewed a proposed unified base image architecture that leverages container files and downstream variants, excluding cloudinit and ignition to minimize attack surfaces. They also discussed handling platform-specific configurations via systemd system extensions and recommended Konflux as the standard build system.

The group established a formal process using Architectural Decision Records (ADRs) to track project decisions. Moving forward, the team officially adopted "Atomic Fusion" as the project name and began scaffolding an umbrella ADR to consolidate their initial architectural choices into a single reviewable document.

Decisions

• Accepted "Atomic Fusion" as the official project name for the bootable image unification effort (Original topic).
• Adopted a formal Architectural Decision Record (ADR) management process, utilizing sequential numbering and proposal PRs to review and ratify architectural choices (Original topic).

Contribution opportunities

• Contributors are invited to participate in consolidating the first round of unified base image architecture decisions on Forgejo Pull Request #2.
• Interested community members can join the discussion in the Bootable Image Unification Matrix channel (Original topic).

Learn more about the Hummingbird team.

Kernel

In a discussion regarding an RFC on splitting perf out of the kernel packaging, Fedora Python maintainers expressed a desire for the split. This separation would allow them to independently rebuild perf for Python packaging changes without requiring kernel-level signing permissions. However, other community members questioned whether this is a significant hurdle, noting that Rawhide kernels are already built almost daily to keep up with upstream changes.

Learn more about the Kernel team.

AI

The AI/ML SIG is making significant progress on the ROCm 10.1 stack, which is currently available in the preview COPR and compiling cleanly with downstream consumers like PyTorch. The updated toolchain introduces LLVM 24, preliminary support for the Khronos SPIR-V standard, and initial compiler support for the gfx1170 APU, with a multi-day Koji sidetag rebuild expected soon.

On the community front, the group agreed to enable an opt-in LLM summarization bot for the This Week in Fedora (TWIF) weekly reports to improve external visibility. Additionally, the SIG is debating a proposal to migrate documentation from the Fedora Wiki to Fedora Docs to align with standard project infrastructure, alongside discussions on authoring new beginner-friendly AI tutorials.

Decisions

• Allow the This Week in Fedora (TWIF) summarization bot to ingest the public SIG Matrix chat history on a trial basis to generate weekly reports for the wider community (Ticket #39).
• Relocate automated Forgejo bot notifications from the main Matrix room to a dedicated, opt-in alerts room to keep human discussions clear of clutter (Ticket #42).
• Grant forge-ai-ml-owners membership to @jflory7 to manage organization-wide labels and webhooks on the Fedora Forge repositories (Ticket #41).

Contribution opportunities

• Community members are invited to participate in the upcoming Fedora/RHEL/CentOS Leads (FRCL) open discussion on "Which LLM-gen-AI models are more aligned with Fedora?" scheduled for October 14 (Ticket #43).
• Contributors are welcome to help draft and shape beginner-friendly getting-started guides for Fedora Linux, focusing on topics like local AI inference (Ollama, RamaLama), GPU tuning, and AI coding agents (Ticket #6).

Learn more about the AI team.

RISC-V

This week, the RISC-V team focused heavily on preparing Fedora 45 (successfully testing Server, Cloud, and Container images) and progressing the Fedora 46 sync, analyzing the content-set diffs compared to the main Koji. Significant effort was directed toward bootstrapping Fedora ELN for riscv64, which involved configuring Koji tags, managing test suite failures in problematic packages, and successfully building LLVM from vanilla Fedora sources.

Kernel development centered on the Omni kernel, with maintainers preparing to adopt the upstream kernel 7.3 for F45. The team also investigated a persistent GCC build segmentation fault on K3 hardware and actively participated remotely in the Linux Plumbers RISC-V Microconference.

Decisions

• Disable the openmpi test suite on riscv64 due to persistent hardware-specific hangs to unblock the Fedora ELN bootstrap.
• Remove the VF2 PCIe patch from the unpatched Fedora 7.3 kernel for Fedora 45, steering users of older hardware toward the Omni kernel instead.
• Disable the MLIR execution engine in LLVM 21.1.1 for RISC-V to bypass unresolved test failures (Issue #2).
• Hold off on manually fixing empty debugsource packages caused by lack of LTO, as GCC 17 will naturally resolve this issue later this year.

Contribution opportunities

• Help is needed from compiler experts to debug and resolve a GCC build segmentation fault on K3 hardware.
• Contributors are invited to help test the Fedora 45 Server, Cloud, and Container RISC-V images.

Learn more about the RISC-V team.

NeuroFedora

The NeuroFedora group has successfully reached out to a non-responsive maintainer and consolidated admin rights for all neuro-packages to streamline review and cleanup efforts. This administrative update supports the team's ongoing initiative to reduce their Python packaging footprint by relying on direct installations from PyPI where appropriate. A dedicated test suite has been implemented to monitor the status of these packages and is now running regularly.

The group is currently reviewing packages that fail to install on Python 3.14 and 3.15 in the new test suite, and is considering limiting their automated tests strictly to pre-compiled wheels. Furthermore, team members have agreed to include their public activity in these weekly summaries for the Fedora community.

Decisions

• Admin rights for all neuro-packages were granted to active team members to facilitate the review and retirement of unneeded packages.
• The team finalized its strategy for reducing its Python packaging maintenance, replacing direct maintenance of some packages with a regular test suite to track compatibility.
• The group approved the collection of their public tracking and discussion data for automated weekly Fedora community reports.

Contribution opportunities

• Provide feedback on packages failing to install on Python 3.14 and 3.15 and discuss whether the test suite should be restricted to checking pre-compiled wheels only.

Learn more about the NeuroFedora team.

Perl

This week, the Perl group focused on maintaining and updating key packages, primarily resolving several lingering pull requests. Maintainers manually incorporated commits to update the rt (Request Tracker) package to version 5.0.10 after encountering merge conflicts, and a new draft pull request was recently opened to push rt further to version 6.0.3.

Additionally, housekeeping efforts led to the closure of older, redundant pull requests in rt and perl-Plack, while a dependency update was successfully merged for perl-Package-Generator to conditionalize Params::Util.

Decisions

• Merged a pull request to conditionalize the Params::Util dependency in perl-Package-Generator.
• Closed an outdated pull request intended to fix build-require paths for rt, as the necessary font build requirements (font(droidsans) and font(droidsansfallback)) had already been updated by maintainers.
• Manually incorporated commits to update rt to 5.0.10 due to merge and rebase conflicts, subsequently closing the original pull request.
• Closed a pull request to drop support for mod_perl in EL9 and later in perl-Plack because the author already possesses repository commit access.

Learn more about the Perl team.

Rust

This week, the Rust community was alerted to a looming issue affecting crun-vm builds. Fabio Valentini notified the maintainers that several of the project's dependencies are currently orphaned and are slated for removal from Fedora within the next one to two weeks. The affected packages include rust-rxml, rust-rxml_proc, rust-weak-table, rust-rxml_validation, and rust-minidom.

Contribution opportunities

• Maintainers are urgently needed to take ownership of five orphaned Rust packages (rust-rxml, rust-rxml_proc, rust-weak-table, rust-rxml_validation, and rust-minidom). Community members must step up to unorphan these packages to prevent crun-vm builds from breaking due to missing dependencies.

Learn more about the Rust team.

Other Discussions

• Shivank Sharma asked if signing the Fedora Project Contributor Agreement (FPCA) automatically grants access to award badges. Akashdeep Dhar clarified that while the admin frontend becomes visible, the user's authorizations dictate which badges they can actually award.
• Miroslav Suchý shared a list of newly added packages in Fedora Linux for September 2026, generated from the rawhide-changes script.
• Gordon Messmer inquired about how to contact the crypto team to add AWS s2n-tls to Fedora, noting that their mailing list is closed to non-members. Dmitry Belyavskiy offered to discuss the issue at the upcoming OpenSSL conference.
• Abdallah Shehawey proposed packaging a source-only version of whatsapp-desktop relying on a system-provided Electron runtime. The discussion highlighted the challenges of maintaining multiple Electron versions in Fedora and keeping dependent packages synced.
• Fabio Valentini reached out to find the maintainer of julia, noting that unmerged pull requests are causing FTBFS errors in Fedora 45 and that the non-responsive maintainer process has been initiated.
• Alejandro Lopez asked why rpminspect was reporting insecure mode failures for a sudo merge request on ELN. Dave Cantrell explained that the rpminspect environment lacked a product definition for ELN, leading to the creation of a new tracking ticket.
• Michel Lind proposed splitting the perf tool out of the kernel packaging to reduce build requirements, simplify the package spec, and avoid requiring kernel rebuilds when updating Python packaging.
• Julian Sikorski asked for advice on adding openh264 as a build requirement for MAME. Neal Gompa and Michael J Gruber recommended using the system package via pkgconfig and stripping the bundled source from the tarball during the prep phase to avoid patent issues.
• Chih-Tao Lee initiated a non-responsive maintainer check for python-authlib and successfully stepped up to co-maintain it alongside the RHEL Lightspeed group.
• Aoife Moloney shared the summary of the latest Fedora Council meeting, noting an agreement to implement a "Decision Support Process" instead of strict Conflict of Interest Guidelines, and starting discussions for Flock 2027 CfP themes.
• Other discussions included a reminder for the Fedora 45 Blocker Review Meeting, a review request for coconut-svsm for confidential computing, a non-responsive maintainer check for Luis Bazan, deleted branches and commits in the glibc-maintainer-scripts repo on the glibc mailing list, and updates in the Fedora Docs Matrix channel covering pull requests for image accessibility, rebuilding site scripts, and FIDO2 PIN commands.

Orphaning packages

• Michael Catanzaro announced he is orphaning WebKitGTK across all branches due to leaving his job, with Fabio Valentini volunteering to take over maintenance.
• Benson Muite announced the orphaning of python-proton-vpn-network-manager due to lack of time to maintain its required dependencies, which now involve Rust.

Package updates

• Richard Shaw updated OpenColorIO to version 2.6, handling an upstream SONAME bump and successfully rebuilding all dependent packages.
• Kaleb Keithley announced an update to Apache Arrow 26.0.0, which includes a libarrow SONAME bump and requires rebuilding dependent packages like ceph and gdal in a side tag.
• Antonio Trande announced that PETSc is being updated to 3.26 in Rawhide and F45, and listed the dependencies that require rebuilding.
• Stephen Gallagher warned of a backwards-incompatible update to python-openai 3.24.0 in Rawhide and F45, making HTTPX2 the default and removing deprecated CLI tools.

New contributors

• Andrew Heath introduced themselves, sharing a decade of enterprise Linux and infrastructure-as-code experience, and is looking for a sponsor to help with packaging, image building, and QA.

All contribution opportunities

Contributors with a passion for Quality Assurance and Testing have numerous accessible entry points to help ensure a stable release. Community members are highly encouraged to shorten review meetings by voting early on proposed Fedora 45 blockers and freeze exceptions for Workstation, KDE, ARM, and Release Engineering using the blockerbugs app. Hands-on testers can jump into the Podman Conmon-v3 Test Days or the KDE Plasma 6.8.0 Test Day. If you prefer trying out new builds, you can claim F45 Beta Server testing tickets, run bare-metal installations on Beaker hardware, or test upcoming RISC-V images.

Those skilled in Technical Writing, Community Feedback, and Documentation can make an immediate impact without deep technical onboarding. Writers and editors are needed to proofread the Beginner's Guide Vorta backup section, draft new AI getting-started guides, and create documentation for Server's new Ansible support. Reviewers can also provide valuable insights by suggesting missing commands for a Git cheat sheet, testing a collaborative Cryptpad instance, or weighing in on broad ecosystem changes like the RPMv6 format transition (feedback ticket) and AI model alignment. Additionally, contributors can help coordinate cross-team efforts by reviewing Bootable Image Unification ADRs or sharing thoughts on Mindshare's committee representation adjustments.

For contributors specializing in Design, Web Development, and Automation, several creative and structural tasks are open. Designers are invited to create CentOS/EPEL hex stickers, design the F46 Beta wallpaper, craft an avatar for the Matrix Moderation bot, and supply a high-resolution SVG Fedora logo for GDM. Web developers can help update apps.fedoraproject.org, replace outdated Zanata references with Fedora Weblate in CMS templates, and assist with website optimization and reusable event templates. Meanwhile, scripters and automation enthusiasts can improve infrastructure by automating AppStream data generation, tester statistics (Heroes of Fedora), mediakit checksums, and Infrastructure tracking groups.

Finally, experts in Software Packaging, Debugging, and Systems Engineering are in high demand to maintain the ecosystem's backbone. C/C++ developers can assist in resolving a GCC build segmentation fault on RISC-V K3 hardware or fixing obs-studio build failures against the new Qt 6.10 framework in EPEL. Maintainers are urgently needed to adopt five critical orphaned Rust packages to prevent VM build breakages, alongside other tools like julia and transifex-client. Systems engineers can make an impact by reviewing untagged AWS resources, evaluating Python test suite restrictions, or assisting with the CoreOS and Atomic unification migration. Members with strong leadership experience can also step up to sponsor the Fedora Docs 2025 Initiative.

13 Oct 2026 9:10am GMT

13 Oct 2026 8:00am GMT

This year's edition of International Calligraphy Festival Keralam was yet another great experience, consisting of workshops, demonstrations and talks surrounding calligraphy & typography, much like the last time. Eminent calligraphers of about a dozen scripts shared their expertise and experience.

Pictures of a sample collection of the calligraphy works at the exhibition below.

For my talk, I presented the historical evolution of Malayalam script from rock inscriptions to the digital age, and how the vigilant volunteer community reclaimed the script with its rich conjuncts and conjoined reph/matra shapes, and made all the foundational digital technologies openly available for public good.

The video recording of the talk is available.

Many type designers, companies and enthusiasts were also at the 4-day programme, enabling lot of productive hallway talks as well. A recurring question was the usage of Open Font License, which I hope to have helped to clarify.

The most useful feedback after the talk came from a good friend, who pointed that my slides didn't do enough justice to the body of work we've done (particularly as open-source); and helped me walk through some possible improvements. I did make some of those changes, and the slides (created using TeX) are made available.

12 Oct 2026 11:58am GMT

12 Oct 2026 12:00am GMT

11 Oct 2026 4:26pm GMT

10 Oct 2026 1:33pm GMT

Theme

Experience

Marking the second Indian FOSS event for me, day zero of IndiaFOSS 2026 by FOSSUnited Organization had the Maintainer Summit planned for it. This had a separate registration apart from the main conference and hence had a smaller footfall at Samagata Foundation. As the invitation email required us attendees to be at the venue at 0900am Indian Standard Time sharp, I decided to get a head start to beat the Bengaluru traffic on Friday, 25th September 2026. As I had my hotel check-in later on that day, I also had to make a brief stop at SRS Springs And Spa Hotel to leave my luggage before finally making it to the event venue. Leaving on an Uber ride at around 0730am Indian Standard Time from Yelahanka Crossing, I surprisingly witnessed much lighter morning traffic than I expected while heading from the outskirts into the metaphoric heart of Bengaluru city.

Simply put, I seemed to have greatly overestimated the traffic situation. Or maybe it was the Friday morning doing wonders. I was able to reach the first stop by around 0815am Indian Standard Time, giving me roughly 45 minutes to cover the next distance. Leaving my check-in luggage with the trusty receptionist of SRS Springs and Spa Hotel, I chatted with the fellow members on the event's official Telegram group until I reached my stop. I was almost certain that I was one of the first folks to make it to Samagata Foundation, after being helped by Ansh Arora in navigating the sprawling center. While Rajan Shah assured me of his availability, he also mentioned that he would join later with Veer Kumar Patil, Shivraj Patil, Deepesh Nair, and Gaurav Kamathe. That not only meant that I was on my own there but also that I had a great opportunity to make some new Fedora friends too!

With the attendees slowly rolling in and leaving their stickers on the swag desk, I made it a point to hand out the Fedora Project round badge / magnet combo to folks I had conversations with. This helped me manage the limited swag inventory wisely while keeping me on my toes to seek out new conversations to be a part of. Many of these FOSS friends were either already aware of the Fedora Project and or were using Fedora Linux, which made it a lot easier for me to seek out possible contributors among the prolific crowd of FOSS maintainers. One such chat that made a lasting, mutually beneficial impact was with the Tangled Project members, who wanted to learn about my progress with the migration from Pagure to Forgejo within the Fedora Project community. We shared our frustrations with the various Git hosting services while we waited for the event organizers to arrive there.

While Forgejo was a fork of Gitea, which itself was a fork of Gogs, Tangled seemed to be built from the ground up and was an interesting external case study to learn features from as we were contributing to the Forgejo upstream. With various other chats on knowledge, localization, programming and community with maintainers, I also ran into people who recognized me instantly from my previous adventures earlier that year in DevConf.IN 2026 and FOSSAsia 2026. As an elected Fedora Mindshare representative who was also a part of the Fedora Council then, this sign meant that our efforts with establishing regional community presence in the APAC region were clearly working. All we had to do was continue doing just that in order to help the adoption of Fedora Linux among users and awareness of the Fedora Project among enthusiasts in a region which was largely ignored until 2025-2026.

Ansh kicked off the unconference-styled Maintainer Summit's event proceedings with his opening note as we gathered at the whiteboard with our sticky notes to propose things that we wanted to discuss. We had varying degrees of success with the instruments like the sticky notes and markers, but it was hilarious to see just how many maintainers it took to redo the entire board with thumbtacks and a stick board. After proposing Contributor Retention in FOSS Communities, I decided to hang back and help out the fellow organizers. In our passing chats, I could not help but notice a healthy skepticism about using generative tooling along with an overriding enthusiasm for where the technology was headed. I, however, did find myself being psychologically alienated from chats that were bordering on virtue signaling about the general utilization of artificial intelligence-based technologies.

In the times when conversations on artificial intelligence were just unavoidable, I wanted to spend more effort exploring how the technology could be evolved more instead of debating its usage prescriptions. I loved just how the event attendees were a healthy mix of technical individuals and non-technical enthusiasts, both of them desiring to understand the core requirements of the other persona. For the first part, I decided to join the contemporary Git Hosting discussion chaired by the Tangled Project contributing maintainers, along with Veer Kumar and Gaurav, who had arrived at the event venue by then. It felt great to meet up with them at yet another APAC conference, along with Rajan, Deepesh and Shivraj, after our last meetings at DevConf.IN 2026 and FOSSAsia 2026, especially with Rajan also standing for the FOSSUnited Organization governing body elections at that time.

Joining in the maintainer discussions around semantic diffs in various Git hosting services and the general need for workflow evolution, I was genuinely surprised to see just how other maintainers faced the same problems that the Fedora Project had been facing for many years. We passed around a smartphone (to act as a mic) in our small groups as we took turns with what we had to say. As the review system had more or less remained the same for a decade now, I stressed how crucial it had become for the various Git hosting services to use generative tooling to provide semantic diffs in order to help streamline collaboration among maintainers and contributors. We reflected upon and agreed on how the wider accessibility of generative tooling had already made it increasingly difficult for fellow maintainers to review large volumes of codebase changes within reasonable turnaround times.

As time passed by, I was surprised to see just how much my proposed topic on Contributor Retention in FOSS Communities amassed supporting sticky notes. All the support my topic ended up getting moved us from a corner area to the center of the conference. Since it was scheduled for 1200pm Indian Standard Time, Rajan and I briefly joined the discussion on India's Digital Personal Data Protection Act and how it compared with Europe's General Data Protection Regulation Act. Apart from the comparisons, we also delved deeper into the maintainer's responsibilities with data protection and how the policy required general awareness for effective enforcement. Touching on the related topics of Europe's Cyber Resilience Act and the United States' Federal Risk and Authorization Management Program, we also distinguished between the roles of software authors and service administrators.

Exploring the frequent Aadhaar data leaks, we reflected on just how important it is for citizens to hold the policymakers accountable for these. While a CRA analogue for India would take a while to come into being, we discussed the best practices for FOSS maintainers to ensure preliminary data safety at their ends on an architectural level. Various case studies were brought up where data security and policy validation were seen as a chore rather than a fundamental responsibility-an observation that I vocally protested about, as a similar attitude towards privacy is what empowers bad actors to discover loopholes in a security policy. Finishing off with this discussion paved the way for the one added by me, and I soon found myself arranging the chairs while preparing for the attendees to arrive. Even when we started off with just five folks, we quickly ballooned to over twenty in no time.

With almost one-third of the unconference population at our discussion, I started off the discussion at around 1215pm Indian Standard Time. We went around the attendees-both technical and managerial in nature-to explore their onboarding experiences from their communities. I was interested to know how the interactions with first-time newcoming contributors went and what made them feel like staying back in a community after their first contribution activity was completed. Gaurav gracefully allowed his iPhone to be used as a mic, and amidst various experiences, I shared a demo of how we incentivized contributions in the Fedora Project with the use of the Fedora Badges platform. As a solution that scaled pretty well across various-sized FOSS communities, they appreciated how this solution could help immensely when shipping swag or attending events could be very difficult.

I appreciated how grounded the conversation was, with people realizing that most of the time, people simply appreciate it if their activities are reviewed in time and not left in a metaphoric limbo. While artificial intelligence-based generative tools ensured that the entry barrier was lowered, to the point that even bad actors went on with spamming activities, we also reflected on just how it was hurting the fellow maintainers. Even Ansh could not help joining in on the chat with his experiences while we were waiting for lunch, and at around 0115pm Indian Standard Time, we were finally done with the first half of the day. Joining a queue a little later with my Red Hat friends, I got myself some plain and simple Indian meal with chapatis, pulses, rice, vegetables and sweets. I loved how the healthy lunch represented the Indian hospitality of the unconference event, much akin to FOSSAsia 2026's food.

Hanging out with the likes of Darsh Shah and Shrirang Kahale during lunch, Deepesh showcased his solar-powered self-hosting homelab. We were pleasantly surprised to learn how Shrirang ran eight GNU/Linux mirrors across the country, all while being in his second year of engineering study. With the Red Hat friends leaving at around 0230pm Indian Standard Time after the mealtime discussions, I hung back to see which chats I wanted to be a part of. After briefly joining the one run by the FOSS maintainers from the Wikimedia Foundation, I had a fairly good and engaging discussion around the usage of artificial intelligence for the starter template before ensuring a human review. My analogue to the healthy skepticism was to utilize generative tooling to fill metaphoric potholes on a figurative road created by humans, and avoid doing things the other way around, if possible.

Plagued by the experiences of LLMs basing their output on citations and resources that most likely do not exist, we reflected on the potential stress on reviewers using human time and effort on them. Observing the growing virtue-signaling around artificial intelligence technologies again, I silently resigned myself to calling it a day at around 0400pm Indian Standard Time. Shrirang and I had some Samosas, and after bidding farewell to Poruri Sai Rahul and Ansh, we decided to depart on an Uber ride waiting for us. As much as I wanted to stay back until the evening for the full-course Maintainer Summit event experience, I knew I had other important things to take care of. Not only did I have to check into the hotel after collecting my luggage from the reception, but I also had to prepare for the first day of IndiaFOSS 2026 to represent the Fedora Project alongside our fellow Red Hat associates.

09 Oct 2026 6:30pm GMT

Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.

RPMs of PHP version 8.5.12RC1 are available

• as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

RPMs of PHP version 8.4.27RC1 are available

• as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux ≥ 8
• as SCL in remi-test repository

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.

ℹ️ Installation: follow the wizard instructions.

ℹ️ Announcements:

• PHP 8.5.12RC1 available for testing
• PHP 8.4.27RC1 available for testing

Parallel installation of version 8.5 as Software Collection:

yum --enablerepo=remi-test install php85

Parallel installation of version 8.4 as Software Collection:

yum --enablerepo=remi-test install php84

Update of system version 8.5:

dnf module switch-to php:remi-8.5
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.4:

dnf module switch-to php:remi-8.4
dnf --enablerepo=remi-modular-test update php\*

ℹ️ Notice:

• Version 8.5.12RC1 is in Fedora rawhide for QA
• Version 8.6.0RC3 is also available in the repository
• EL-10 packages are built using RHEL-10.2 and EPEL-10.2
• EL-9 packages are built using RHEL-9.8 and EPEL-9
• EL-8 packages are built using RHEL-8.10 and EPEL-8
• oci8 extension uses the RPM of the Oracle Instant Client version 23.26 on x86_64 and aarch64
• intl extension uses libicu 74.2
• RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
• versions 8.4.19 and 8.5.4 are planed for March 12th, in 2 weeks.

Software Collections (php84, php85)

Base packages (php)

09 Oct 2026 5:00am GMT