Being an official part of Fedora means that it is composed and supported by Fedora Release Engineering (releng). Release Engineering bestows this status on items that successfully make its way through our Manufacturing Train and satisfy all related policies. With this status the item is Open, Integrated, Reproducible, Auditable, Definable, and Deliverable in no particular order.

This document provides definitions for each of those terms, why they are important, and how we guarantee them.

All parts of Fedora should strive to be meet all parts of being official at all times.

It goes without saying that Fedora is built on the four F’s.

In Release Engineering we are no different, we require everything to be open. That is open source, developed in the open, available for all to look at, use and contribute to. All downstreams should be able to take our tooling and make their own derivative of Fedora, either by rebuilding everything, perhaps with different options or just adding their own marks and packages and re-composing.

At any time anyone should be able to see how Fedora is put together and put together their own version of Fedora.

Fedora is a huge project with a massive number of ever-growing deliverables. This means when we add new deliverables we need to have the composing of them tightly integrated into the process. We ship Fedora a whole unit, so we need to make it as a whole unit.

Any new tooling we use must be consistent with the existing tooling in how it works.

The tooling has to ensure that the output is Reproducible, Auditable, Definable so that it can be Deliverable.

A reproducible component is one we can rebuild from scratch at any time with less than a day’s worth of effort. It implies we can look up all of the source code, and know exactly what revisions to use from source control. We know exactly what tools are used in the build environment to transform the source code into product content (binaries). We also know how to reproduce the same build environment to ensure the tools behave like we expect. This aspect is why Release Engineering is in the business of standardizing on build tools.

Reproducible components are important because they are a lot easier to maintain. The Security Team takes advantage of this aspect of a Product. Not knowing how to rebuild a subsystem in a product to apply security fixes, or bug fixes, makes their job much more difficult. It would be a significant risk to provide a product to users that we are incapable of building again. Not knowing the origin of source code is also a significant risk, which is why many of our build environments are configured to prevent tools from dynamically downloading content from the internet.

The combination of Koji and fedpkg is what enables Release Engineering to rebuild a component.

fedpkg manages the source code in our dist-git system and Koji archives details about the build environment, the tools used, logs, and of course the binaries themselves.

Fedora and Red Hat expect auditable output too, which means Release Engineering knows who built what, when, and where (and how, but that is Reproducibility). Being able to authoritatively say that something was built within Fedora by people who have signed the FPCA (Fedora Project Contributor Agreement) is important for several reasons. One big reason is that it promotes and fosters accountability within the community. It promotes ownership. Another is more defensive. In the event of a security breach, we have a lot of evidence and data prepared to help us identify what content (if any) was compromised. If a kernel RPM randomly shows up, and we have no records of building it and/or shipping it, that should raise a lot of alarms very quickly!

Red Hat’s InfoSec Team and Fedora Security Team care about this aspect deeply. We should never be in a position where we cannot definitively answer why a piece of content is available to users. This aspect is also a key part of the verification that is done when Fedora becomes RHEL. All downstream consumers of Fedora expect that they can verify the code and binaries that they consume from Fedora.

Release Engineering tracks this data in 2 systems: Koji and Bodhi.

Koji uses SSL certificates tied to Fedora Account System (FAS) and Bodhi uses FAS for authentication in order to provide a strong relationship between a user and the content.

Koji builds the content, Bodhi tracks the bugs, documentation, and enhancements associated with the content and actually does the delivery. Bodhi maintains records of what was shipped when and where, and who pushed it.

The ability to define and predict content is necessary as well. It is important to know exactly what was included in a release. It helps protect against shipping content that unnecessarily causes a support burden. This aspect of a Fedora component helps support other aspects like reproducibility. There is no need to reproduce software we do not ship. Ensuring the product content is lean and trim may sound obvious, but in the world of sprawling RPM dependencies, Maven artifacts, and Ruby gems, it is actually rather easy to include content during the course of a multi-month or multi-year development cycle.

Furthermore, a definable component has the changes made to it vetted and understood by multiple teams. They are not made in an ad-hoc manner or without consent from FESCo, QA, Release Engineering, and/or the Product Working Groups that contribute at the program level. This reduces change risk to the user, which our users and downstreams like to hear.

Many systems help make components definable. Release Engineering uses Bugzilla, dist-git, Bodhi, and Blocker Bugs.

Official parts of Fedora are eligible to be delivered to /pub/fedora/ or /pub/alt/releases/ on Fedora Download and to get mirrorlists in mirrormanager.

These Distribution Platforms are maintained by Fedora Infrastructure and Release Engineering. This is not a feature of the product content itself or how it was built, but rather how it was delivered to users through Release Engineering’s processes. Those platforms are geographically replicated by the volunteer mirror network. They provide a reliable and durable service that ensures users can always reach Fedora for updates, even in the event of a disaster affecting our data center in rdu3.

User support and Fedora Security Team depend on these services.

It is vital for critical security fixes and updates to always be available to users.