Fedora Rawhide Gating

The following pages document the recently enabled gating mechanism in Fedora Rawhide.

The aim of this initiative is to set up the infrastructure so that packages can be gated based on test results before they are allowed into Fedora Rawhide. This will reduce the amount of broken dependencies, uninstallable packages, and broken composes, and will ultimately lead to a more stable Rawhide. As an added benefit, this framework will also lessen the burden on the infrastructure and release engineering teams that ensure composes keep working.

Reasons for Gating

The basic principle of this proposal is to provide an environment in which packages can be built and tested without affecting other packages.

When looking at how Rawhide package updates are gated on test results, we need to consider two workflows: single build updates, in which the contained build is only loosely coupled to other builds, and multi-build updates, in which the builds are tightly coupled.

  • For a single build, the easiest solution is to provide a dedicated Koji tag in which these packages are built, and where they wait for their tests to pass before they can enter the buildroot.

  • For multiple builds, the solution is to rely on “side-tags” in Koji. These side-tags are basically tags created by the packager and available to them to do their work, in this case rebuild all the packages desired. The side-tag can then be sent to the test system as one unit of change.

To use a now well-known analogy, a single build update is like sending a commit to a mailing list: it waits there to be reviewed and tested before being merged into the main repository. Multi-build updates are more similar to pull-requests: they can contain one or more builds which are reviewed and tested together as one change before being merged.

Rawhide is a unique place in the Fedora ecosystem: It is the only place where large changes and rebuilds can be done. In stable Fedora releases, rebuilding large sets of packages is discouraged by the packaging guidelines, so the ratio of single- vs. multi-build updates in Bodhi (95% to 5%) is not reflective of the realities of the Rawhide ecosystem.

The aim of Rawhide Gating is to build the infrastructure allowing to gate packages in Rawhide. The idea is for packages to go through Bodhi, be tested, and land in the Rawhide buildroot as they do today if the tests pass. In the simplest case, the packager workflow will not be impacted by this proposal; more complicated situations will require adjustements to the packager workflow. However, these adjustments are minimal.

No tests are being made mandatory as this framework is introduced. It is up to the community (and FESCo) to decide if any, and if yes, which rules should be enforced for all packages.

Additional Reading

Want to help? Learn how to contribute to Fedora Docs ›