- 1 Overview
- 2 General Development
- 3 CI Tests
- 4 Rebases
- 4.1 Step 1: File a System Wide Change Proposal
- 4.2 Step 2: Request a side tag
- 4.3 Step 3: Request dist-git repos for compatibility packages
- 4.4 Step 4: Create the compatibility packages
- 4.5 Step 5: Do initial builds in the side tag
- 4.6 Step 6: Merge side tag into rawhide
- 4.7 Step 7: Stabilize the packages
This guide is intended for packagers working with any of the llvm sub-projects, which include:
Please submit pull requests for major changes. This will allow the CI tests to run and give other developers a chance to review.
The goal of the CI tests should be to test integration of llvm packages into the system. Tests for specific upstream bugs are not necessary, but any Fedora bugs that are caused by interactions with another package should have a CI test added when they are fixed.
A rebase is an upgrade that changes the major version of LLVM (e.g. upgrading from X.0.1 to (X+1).0.0). For each upstream release we would like to start the upgrade process when the first release candidate is released. Packaging the first release candidate gives us a chance to test and fix issues in Fedora so we can get fixes back upstream before the final release.
Step 1: File a System Wide Change Proposal
A Change Proposal should be filed to notify Fedora users and developers that LLVM will be rebased in the next Fedora release. Make sure to follow the Fedora release schedule and file the change proposal before the Change Checkpoint.
Step 2: Request a side tag
Step 3: Request dist-git repos for compatibility packages
Create a compatibility packages for clang and llvm for the current release in rawhide Using the
fedpkg request-repo command. The packages should be called clangX.Y and llvmX.Y, where X.Y.z is the current version of LLVM in rawhide.
Compatibility packages do not need a full package review, so you can use the --exception flag when creating them.
Step 4: Create the compatibility packages
You can re-use the existing spec files from the clang and llvm dist-git when creating the compatibility packages. You just need to change the compat_build option to enabled by default:
%bacond_with compat_build -> %bcond_without compat_build
Step 5: Do initial builds in the side tag
Do local or scratch builds of each llvm sub-project to make sure they build successfully in rawhide. Once you have confirmed that everything works, you can start submitting your builds to Koji.
The goal at this stage is to get builds into rawhide. It is OK to disable tests and ignore minor failures at this stage.
Step 6: Merge side tag into rawhide
Comment on the releng ticket in Step 2 and ask for the side tag to be merged into rawhide.
Step 7: Stabilize the packages
Continue to stabilize the packages in rawhide and any branched releases until all CI tests are passing and major bugs resolved.