Kubernetes updates for Fedora Linux 37 have been on hold pending an update to the version of Go available Go has now been updated (thanks Alejandro Sáez!). Kubernetes 1.25.15 was submitted to testing on 29 October and will be available for general download 1 week later. See Fedora dist-git for current information on what versions of Kubernetes are available for Fedora in stable and testing.
Kubernetes v1.25 is the version available for Fedora Linux 37 from Fedora repositories. Starting with Kubernetes v1.25.12, Kubernetes developers changed the version of the go language used to compile Kubernetes from v1.19 to v1.20. Fedora 37 currently provides go language v1.19. As a result, the latest version of Kubernetes available in the Fedora repository is v1.25.11 which is several versions behind the current v1.25 release. Kubernetes v1.25.12 included an important security patch for clusters that include Windows nodes.
Continue readingPackage reviews are an important part of how Fedora delivers well-built RPMs. When one contributor wants to add a new package, another packager has to check it first. It’s how we all hold each other to the high standard we’ve set for ourselves. Of course, that means to add a new package to the repos, you first have to find someone to do the review. Last week, I added a new way to do that: the Package Review Swaps category on Fedora Discussion. Huge thanks to Felix Kaechele for the idea and initial process design.
Continue readingOn behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce!
All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at https://docs.fedoraproject.org/en-US/legal/. Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki.
The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at https://gitlab.com/fedora/legal/fedora-license-data. This data is then presented in easy tabular format in the documentation, at https://docs.fedoraproject.org/en-US/legal/allowed-licenses/.
Historically, this information was listed in tables on the Fedora Wiki. This was hard to maintain and was not conducive to using the data in other ways. This format will enable automation for license validation and other similar process improvements.
We’re changing the policy for the “License” field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects.
Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated.
Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way.
The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that!
A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums.
Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/
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 readingIn 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 readingHow 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 readingIt’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 readingAfter 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 readingAt 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.
Bug reports coming from abrt recovered to roughly the historical average after a surprisingly low F32.
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.
The good news is that we are getting faster at fixing the bug reports that we do fix.
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.
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.
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.
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.
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.
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.
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.
Copyright © 2023 Fedora Community Blog
This work is licensed under a Creative Commons Attribution 4.0 International License.
Theme by Anders Noren — Up ↑
Recent Comments