This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.

What does it mean to “release Fedora”?

Fedora operating system releases are (largely) time-based activity where a new base operating system (kernel, libraries, compilers) is built and tested against our Editions for functionality.  This provides a new source for solutions to be built on. The base operating systems may continue to be maintained on the current 13 month life cycle — or services that extend that period may be provided in the future.  A solution is never obligated to build against all currently maintained bases.

What does this mean for today’s Editions, Labs and Spins?

We are not moving your cheese. At least, not very far. Today’s outputs are essentially unaffected, except in being granted more freedom.  It becomes easier for these solutions to release on their own cadence and to provide alternative software (which could be consumed by other solutions) to meet their users’ needs. We may want to release (for example) Fedora CoreOS completely separately from the base OS refresh, and have a marketing splash entirely around that solution and what the new release does for its target audience.

Labs and Spins are no longer required to be named as such — within the project, they are “Solutions”. (If you like the term “Lab” or “Spin” for something you’re making, feel free to keep calling it that!) These Solutions are “vertical” in that they consume various services to solve their target use case.  Solution builders are free to build their solutions on anything the Project has to offer that meets their needs.

Solutions may have access to different services based on criteria set by those vertical service providers, possibly following strategic guidance set by the Council or following recommendations from Mindshare.  For example, the Website Team support in the form of presentation on the main downloads page may be restricted to solutions with a large user base. Solutions with smaller user bases can grow their usage and gain access to this.

We are retaining the idea of Editions to denote those solutions we use as a test-gate for our releases.  These are our showcases that we will advertise heavily to users and use as a way of framing conversations about the project.

What about solutions that need long or short release cycles?

This is an area where we want the Fedora platform to shine. Modularity enables us to provide multiple versions of applications simultaneously, solutions can release frequently with what have traditionally been thought of as blocking upgrades. This means that these high-speed solutions can keep growing.

When a solution requires frequent changes to the base operating system to meet its need, the entire Fedora platform benefits.  These solutions can also be building block or service providers. Therefore if, for example, an IoT solution requires more frequent base library upgrades, another solution can also choose to use those rapidly updating base libraries as part of their build too.

This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.

The Council’s updated strategic direction guidance is intentionally high-level, which means you probably have a lot of questions about what it actually means for you. If you’re a Fedora packager or a software developer, here’s some more concrete answers.

What does this mean for Packagers and other groups like them?

Packagers remain free to provide software at the versions and cadence they wish. However, that doesn’t mean they can block others providing the same software in different versions and cadence. For example, if you only want to work on the very latest version of a particular piece of software as it comes from upstream, that’s cool — but you have to leave room for someone else who wants to maintaining older releases of that same software.

This isn’t necessarily new — we’ve seen this with, for example, co-maintainers where one person works on the main Fedora OS package and someone else maintains an EPEL branch. But this goes further with features and even bugs. Perhaps a Fedora solution like CoreOS or the Fedora KDE Plasma desktop needs a slightly different version than the “main” one to enable (or strip down) some particular feature. That’s okay! We have multiple stream branches to allow this.

The same is true for changes and other ideas, including greater automation in packaging. Perhaps someone wants to provide a stream where updates are automatically triggered when upstream makes a release. Or maybe someone wants to try out a whole new way of generating specfiles from templates. We don’t block people out, instead we provide options.  There is no obligation for packagers or others to provide all possible options, but we also don’t want to restrict those options from being provided by someone who is interested.

What does this mean for software developers?

Software developers will be able to use Fedora to develop software by selecting the building blocks that make their development environment.  These development environments are essentially highly-tailored solutions with extremely specific applicability. Additionally, the output of software development is a building block that other solutions can use.

Ideally, Fedora becomes the reference architecture for the next generation of software development. More flexibility in package branches will make that possible — if what we have isn’t a perfect match, there can be options within the project rather than requiring people to instead look elsewhere.

This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.

What is actually changing?

This strategy is an ideal we’d like the project to work towards, but it’s also a path that we’re already on. Some parts of this aren’t a change at all, but a clarification of the general consensus over the last few years.

Project Terminology and Teams

We want “Fedora” to be the Project. For things Fedora makes, we’ll describe them as “Fedora Thingname”, like “Fedora IoT” or “the Fedora RPM Package Collection”. I’ve been saying this for a while, but I want to make it official. (Just as “Red Hat” isn’t RHEL.)

We’re going to set up a hosted Taiga instance (more on this soon). Anyone in Fedora will be able to create a project there, and every team in Fedora should. This will create a directory listing which will supplant The Subprojects wiki page and have three significant advantages:

1. Available all in one place
2. Searchable in a reasonable, non-wiki way
3. Not a wiki: inherently self-updating and sortable by activity

This is the minimum required to be a Fedora Team. Teams may have more formalized membership, a charter with rules for voting, regular meetings, regular reports to FESCo or Mindshare, etc. We decided against formalizing rules for words like “Working Group” or “Subproject” and instead agreed that any Team can use those labels if they like.

Teams providing services should formalize a menu of offerings. They should describe the criteria by which those offerings are provided. I think the Council should provide some standard ideas for reasonable criteria. These could include team structure and activity level, user base, a link to current Fedora Objective, etc.

More Autonomy

We need a way for Teams to release artifacts in a self-service way. The Astronomy spin (to pick a random example) should not need to wait for release engineering to make a release. In fact, they might choose to make new releases around the cadence of their most important included software. At the same time, since the Team can do it themselves, Release Engineering might also not be on the hook for building artifacts for spins with a niche audience or that don’t meet some other criteria.

We need to allow for non-RPM building blocks somehow. I mean, not in a technical way but in a rules way. We need to allow for RPMs built in non-traditional ways (the source git idea). No solution is forced to consume these, but we shouldn’t block someone from providing them, either. For example, Silverblue may want to provide some Flatpaks that are built (in an open and transparent from-source way) straight to Flatpak rather than going through RPM. Or AI/ML may want to generate and ship container images with python wheels built specially.

 

We need to relax policies on what Solutions are allowed to do. We also want to drop the Spins/Labs naming thing — it’s confusing to people even within the project. Solution-makers should know their audiences best and should be able to make more technical choices — the things currently known as Spins should be able to offer different defaults and presets, even including enabling different module streams by default. Solutions should not require Spin SIG (or FESCo) approval on technical merit or perceived feasibility.

Overall

We need to be able to adapt to the changing world without taking 18 months to do so each time.