Category: Development (page 1 of 13)

All articles in this category are related to the various Development teams in the Fedora Project, such as package maintainers, quality assurance, and more.

Backwards-incompatible changes in Bodhi

The 6.0 release of Bodhi — Fedora’s update gating system — will be published in a few days. We will deploy it to production a couple weeks after the Fedora release. It includes backwards-incompatible changes. Here’s what you need to know.

Continue reading

Anaconda is getting a new suit and a wizard

In January, we published “Anaconda is getting a new suit” to let you know that we’re looking to modernize and improve Anaconda’s user experience. Before starting the redesign work for the Anaconda installer, the team reviewed user feedback and usability study data that we’ve gathered over the years. 

Continue reading

Collecting ideas for “Feature Spotlight” articles

How do we – as in, the developers and package maintainers who are working on Fedora Linux – make sure people actually know about all the cool stuff we’re doing? That’s the question at the heart of previous discussions on the “devel” mailing list (How do we announce new packages?) and on discourse (Idea for collecting “Cool New Features / Cool New Packages” article ideas).

As it turns out, the answer to that question is: “If what you’ve worked on isn’t big or noteworthy enough, then there’s no place for you”. That’s not good, and it’s why I started working on “Feature Spotlight”.

Continue reading

Anaconda is getting a new suit

It’s quite some time since we created the current GTK based UI for Anaconda: the OS installer for Fedora, RHEL, CentOS. For a long time we (the Anaconda team) were looking for possibilities to modernize and improve the user experience. In this post, we would like to explain what we are working on, and—most of all—inform you about what you can expect in the future.

Continue reading

F35 retrospective results

After the release of Fedora Linux 35, I conducted a retrospective survey. I wanted to see how contributors felt about the release process and identify possible areas we can improve. There was no particular reason to start this with F35 except for that’s when I got around to doing it. So how did F35 go? Let’s look at the results from the 63 responses.

Continue reading

Looking at Fedora Linux 33 bugs

At Nest, I delivered a talk called “Exploring Our Bugs“. But a single snapshot isn’t very useful. Building on the work there, let’s make this a regular thing. With the recent Fedora Linux 33 end-of-life, I’ve added F33 bugs to the bug exploration notebook. Here’s a few of my key findings.


After a drop in bug reports in F32, F33 had about as many bug reports as F31. This is reflected in both bugs marked as duplicate and non-duplicate bugs.

Duplicate bug reports by release

Bug reports coming from abrt recovered to roughly the historical average after a surprisingly low F32.

Sources (abrt or non-abrt) of bug reports by release

We fixed roughly the same amount of F33 bugs as in the last few releases. But with the increase in overall bugs, that means we left more unfixed bugs this time around. The dramatic increase in bugs closed EOL reflects this.

Bug reports by closure type each release
Percentage of bug reports closed end-of-life by release

The good news is that we are getting faster at fixing the bug reports that we do fix.

Mean and median time to “happy” bug report resolution by release.

New graphs!

I re-downloaded the historical data to add some additional fields. This allowed me to take a look at a few areas we hadn’t examined previously.


The first area I wanted to look at is the number of bugs tagged as being security-related. Fedora Linux 33 had the highest count of security bugs, with over 1200. Looking at the graph, there’s a big jump between F26 and F27. This suggests a process change. I’ll have to check with Red Hat’s product security team to see if they have an explanation.

Security bugs by release

The good news is that we’re fixing more security bugs than we’re not. The bad news is that the proportion of security bugs going unfixed is increasing. To be more correct, more bug reports are not marked as fixed. Security fixes often come in upstream releases that aren’t specifically tied to a Bugzilla bug.

Fixed and unfixed security bugs by release

Like with other bug reports, we’re fixing security bugs fixed faster than in the past. 50% of security bugs are resolved within about two weeks.

Mean and median time to resolution for security bugs by release

QA processes

I also wanted to look at how our QA processes are reflected in the bugs. During discussion of an F35 blocker candidate, Adam Williamson commented that it seemed like we were being looser in our interpretation of release criteria lately. In other words, bugs that would not have been blockers in the past are now. The numbers bear this out. While the number of both accepted and rejected blockers is down significantly from F19, there’s a general upward trend in accepted blockers from F30.

Accepted and rejected blockers by release

We have a big increase in accepted freeze exceptions recently. In fact, it looks exponential. Interestingly, the number of rejected freeze exceptions are roughly the same in that time.

Accepted and rejected freeze exceptions by release

Finally, I was curious to see if our use of the common bugs mechanism has changed over time. It has: we mark far fewer bugs compared to five+ years ago. I will be interested to see if the experiment that uses Ask Fedora to handle common issues changes the trends at all. We’ll have to wait until May 2023.

Number of bugs tagged as a common bug per release


The graphs are pretty, but what do they mean? We have to be careful to draw too deep of conclusions. What’s in Bugzilla represents bug reports, not necessarily bugs. Some reports aren’t actual bugs and some bugs don’t have reports. And there’s a lot of “why” that we can’t pull from a summary analysis.

That said, it’s clear that we’re getting more bug reports than we can handle. Some of these should properly be filed upstream. How can we improve on the rest? We can’t do it all at once, but perhaps by working on some subset, we can make improvements. The one that jumps out to me is the security bugs. Can we bring more attention to those? I’ll spend the holiday break thinking about how to make them more visible so that they’re fixed or handled more quickly.

In the meantime, I’d love to hear your ideas, too. If you’d like to examine the data for yourself, everything is in the fedora-bug-data repo.

tmt hint 02: under the hood

After making the first steps with tmt and investigating the provisioning options let’s now dive together a little bit more and look Under The Hood to see how plans, tests and stories work together on a couple of examples.

Continue reading

CPE to staff EPEL work

We are pleased to announce that Red Hat is establishing a small team directly responsible for participating in EPEL activities. Their job isn’t to displace the EPEL community, but rather to support it full-time. We expect many beneficial effects, among those better EPEL readiness for a RHEL major release. The EPEL team will be part of the wider Community Platform Engineering group, or CPE for short.

As a reminder, CPE is the Red Hat team combining IT and release engineering from Fedora and CentOS.
Right now we are staffing up the team and expect to see us begin this work from October 2021. Keep an eye on the EPEL mailing list and the associated tracker as we begin this exciting journey with the EPEL community.

Exploring our bugs, part 3: time to resolution

This is the third and final part of a series I promised during my Nest With Fedora talk (also called “Exploring Our Bugs”). In this post, I’ll analyze the time it takes to resolve bug reports from Fedora Linux 19 to Fedora Linux 32. If you want to do your own analysis, the Jupyter notebook and source data are available on Pagure. These posts are not written to advocate any specific changes or policies. In fact, they may ask more questions than they answer.

Continue reading

Exploring our bugs, part 2: resolution

This is the second part of a series I promised during my Nest With Fedora talk (also called “Exploring Our Bugs”). In this post, I’ll be analyzing the bug report resolutions from Fedora Linux 19 to Fedora Linux 32. If you want to do your own analysis, the Jupyter notebook and source data are available on Pagure. These posts are not written to advocate any specific changes or policies. In fact, they may ask more questions than they answer.

Continue reading

Copyright © 2022 Fedora Community Blog

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Theme by Anders NorenUp ↑