130 lines
6.7 KiB
Text
130 lines
6.7 KiB
Text
[[philosophy]]
|
|
== Fedora Release Engineering Philosophy
|
|
|
|
Being an official part of Fedora means that it is composed and supported
|
|
by Fedora Release Engineering (releng). Releng bestows this status on
|
|
items that successfully makes its way through our Manufacturing Train
|
|
and satisfies 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're important, and how we guarantee them. All parts of
|
|
Fedora should strive to be meet all parts of being official at all
|
|
times.
|
|
|
|
=== Open
|
|
|
|
It goes without saying that Fedora is built on
|
|
https://fedoraproject.org/wiki/Foundations[the four F's]. In releng we
|
|
are no different, we require everything 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 otions or just adding thier own marks and packages and
|
|
recomposing. At any time anyone should be able to see how Fedora is put
|
|
together and put together their own version of Fedora.
|
|
|
|
=== Integrated
|
|
|
|
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 needs to 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.
|
|
|
|
=== Reproducible
|
|
|
|
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 releng is in the business of
|
|
standardizing on build tools.
|
|
|
|
Reproducible components are important because they make them a lot
|
|
easier to maintain. The Security Team takes advantage of this aspect of
|
|
an 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 (or merely unsure) of how to build 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 releng 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. The reproducibility aspect of a
|
|
product is the primary reason we require all products be built in Koji
|
|
if they seek to be an officially supported part of Fedora.
|
|
|
|
=== Auditable
|
|
|
|
Fedora and Red Hat expect auditable output too, which means releng knows
|
|
who built what, when, and where (and how, but that's reproducibility).
|
|
Being able to authoritatively say that something was built within Fedora
|
|
by people who have signed the FPCA is important for several reasons. One
|
|
big reason is it promotes and fosters accountability within the
|
|
comunity. It promotes ownership. Another one 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 pretty quickly!
|
|
|
|
Red Hat's Infosec team and Fedora Security 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.
|
|
|
|
Releng tracks this data in 2 systems, 1 of which we own: Koji and Bodhi.
|
|
Koji uses ssl certs tied to FAS and bodhi uses FAS for authentication to
|
|
provide a strong relationship between a user and the content. Koji
|
|
builds the content of course, the 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.
|
|
|
|
=== Definable
|
|
|
|
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. No need to reproduce software we do not have to
|
|
ship, right? 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 manor or
|
|
without consent from FESCo, QA, releng, and 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. Releng uses Bugzilla, trac,
|
|
blocker bugs and bodhi to track additions and changes.
|
|
|
|
=== Deliverable
|
|
|
|
Official parts of Fedora are eligible to be delivered to `/pub/fedora/`
|
|
or `/pub/alt/releases` on https://dl.fedoraproject.org/pub/[Fedora
|
|
Download] and to get
|
|
https://mirrormanager.fedoraproject.org[mirrorlists] in
|
|
https://github.com/fedora-infra/mirrormanager2[mirrormanager]. These
|
|
Distribution Platforms are maintained by Fedora Infrastructure and
|
|
releng. This is not a feature of the product content itself or how it
|
|
was built, but rather how it was delivered to users through releng'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 phx2.
|
|
|
|
User support (user mailing lists and [.title-ref]##fedora#) and Fedora
|
|
Security team depend on these services. It is vital to that critical
|
|
security fixes and updates are always available to users.
|