This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the Package maintenance guide for that.
- For details of the policy on requirements for updates at various stages of the Fedora Release Life Cycle, refer to Updates Policy.
Overview
This page is intended for new and existing package maintainers. Testers and regular users may be interested in the updates-testing repository and the update feedback guidelines. This page specifically covers the update submission process.
There are two significantly different package update submission workflows in Fedora:
- Rawhide, and Branched up to the Bodhi enabling point
- Branched releases after the Alpha change deadline, and stable releases
The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.
Rawhide and early Branched
The package update workflow for Rawhide and Branched before the Bodhi enabling point is simple:
- Build the package with
fedpkg build(see the Package maintenance guide for more details)
This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.
Later Branched and stable releases
At the Bodhi enabling point, the Bodhi update feedback system is enabled by Release Engineering and builds submitted with fedpkg build are no longer automatically sent to any official repository. The update workflow for releases of this type is:
- Build the package with
fedpkg build - Submit an update for the package with
fedpkg updateor via the Bodhi web interface. This causes the package to be sent to the updates-testing repository - After the update meets the criteria in the Updates Policy, submit the update to stable with
bodhi -R stableor the web interface
At the time you submit the update, you may set a karma (feedback) level at which the update will automatically be submitted to stable. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as 
firefox
When a release is in Branched state, the updates-testing repository is enabled by default so most users will see the package, but only packages from the stable fedora repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.
Where a package goes when it is marked as stable differs between Branched and stable releases. In Branched releases, stable packages are pushed to the base fedora repository. In stable releases, stable packages are pushed to the updates repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see Repositories.
When a release is in stable state, the updates-testing repository is disabled by default, but QA team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as stable and reaches the updates repository.
Branched milestone freezes
For a short period before each milestone release, the stable fedora repository is frozen. These periods are shown as the Change deadlines on schedules. During these periods, builds will not be marked stable and pushed from updates-testing to fedora even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a Go_No_Go_Meeting. If you believe your update deserves to break a milestone freeze, a freeze exception may be granted through the freeze exception process. Accepted release blocking bugs are granted the same status through the blocker bug process.
For more on the Fedora development process, see Fedora Release Life Cycle.
koji latest-pkg fXX (where XX is the release).New package submissions
If you want to build a new package, but you aren't sure which releases to send it to:
- New packages should always be built for Rawhide
- New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm
The submission process for new packages, after they have passed the Package_Review_Process and been given an SCM repository, is exactly the same as that for package updates.
Consider creating a package test plan
If you create test cases for your package, and categorize them appropriately, they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.