# How updates work in CentOS

This document is an attempt to explain the relationship between Fedora Linux, CentOS Stream and RHEL, with a specific focus around how package updates flow between them.

## From Fedora to CentOS Stream

Fedora is where day-to-day development and innovation happens. Fedora Linux releases every 6 months and each release is maintained for about 13 months. Major changes should be (and almost always are) deployed in Fedora first, following the [Change process](https://docs.fedoraproject.org/en-US/program_management/changes_policy/). Fedora packages sources are maintained in [dist-git](https://src.fedoraproject.org) and built in [Fedora Koji](https://koji.fedoraproject.org).

At the beginning of the development cycle of a new CentOS major release (meaning, `9`, `10`, etc.), Fedora is branched into the new distribution. Historically, this is done from the current stable Fedora release at the branching time (e.g. Fedora 34 for CentOS Stream 9). After the distribution is branched, the development cycle for the new CentOS Stream release begins.

Nowawadys, [Fedora ELN](https://docs.fedoraproject.org/en-US/eln/) helps prepare for the branching process by continuously rebuilding Rawhide (the development version of Fedora). This provides a view into what a new CentOS Stream could look like if it were branched from Fedora today, and ensures that the spec file logic stays compatible with the future set of EL macros and build flags at any given point in time.

## From CentOS Stream to RHEL

CentOS Stream package sources are maintained in [GitLab](https://gitlab.com/redhat/centos-stream/rpms), and that is where most of the distribution [development work](https://gitlab.com/groups/redhat/centos-stream/rpms/-/merge_requests) happens after branching. Packages are built on the [CentOS Stream Koji](https://kojihub.stream.centos.org) and are delivered as part of regularly-produced [distribution composes](https://composes.stream.centos.org/). Composes for Stream are generated 2-3 times a week, and they usually include updates that have been released during that time window, but there is no actual SLA around updates flowing into Stream.

RHEL point releases are essentially, but not actually, a snapshot in time of a given Stream compose, with actual development work happening on the Stream side and showing up there first. In general, a given package will go through QA, then land into Stream, then down the road be incorporated into the next RHEL minor release. In this sense, Stream acts as a continuously-delivered preview of the next RHEL minor release. Aleksandra Fedorova also talks about this process in detail in her [OpenInfra Summit talk](https://www.youtube.com/watch?v=yf1wO5Iu8uY).

Once a given RHEL release is out, the corresponding sources are delivered on git.centos.org, where they can be consumed by RHEL rebuild projects such as Alma Linux and Rocky Linux.

## Deep dive: critical security erratas
As explained above, the general assumption is that packages will land in CentOS Stream first. There is one exception to this, which is embargoes security fixes and security erratas rated critical or important. These are developed by Red Hat and held until the embargo expires. They are then released to RHEL first, and then flow into Stream.

There's two practical scenarios at hand here.

### RHEL and CentOS Stream have a package with the same NVR
When an errata comes out for RHEL, the package is updated there. In this case, you will see the same NVR that came out for RHEL come out for Stream as well.

The recent [polkit CVE](https://koji.mbox.centos.org/koji/buildinfo?buildID=20924) is a good example of this: both RHEL 8 and C8S were at polkit-0.115-11.el8_4.1 before the CVE, and polkit-0.115-13.el8_5.1 fixes the CVE in both.

### CentOS Stream has a package with a greater NVR than RHEL
In this scenario, CS is ahead of RHEL for a given package. When an errata comes out for RHEL the package is updated there, but its version remains behind the Stream one. In this case, assuming the update still applies to the CS version, a new update will be made for Stream, either by backporting the changes onto the latest Stream package version or by rebasing the package.

[libxml2](https://koji.mbox.centos.org/koji/buildinfo?buildID=17568) is a good example of this: before the CVE, RHEL was at libxml2-2.9.7-9.el8, and issued a fixed package as libxml2-2.9.7-9.el8_4.2. Within Stream, the fix was included in libxml2-2.9.7-11.el8.

## Deep dive: CentOS Stream 8
CentOS Stream 8 was the first version of CentOS where the Stream development process was introduced, and has some significant differences. Notably:
- CentOS Stream 8 package sources are hosted on git.centos.org (under the `c8s` branch) instead of GitLab
- because of technical limitations, the contribution process for CentOS Stream 8 is different; the standard PR workflow isn't supported, and the best way to contribute patches is by attaching them to a Bugzilla ticket against the relevant component
- CentOS Stream 8 packages are build on the [Koji mbox instance](https://koji.mbox.centos.org)

There is ongoing work to migrate CentOS Stream 8 onto the current development process and tooling, and the hope is to eventually minimize and hopefully eliminate these differences.