Doku Wiki

First pass at describing the Fedora update/upgrade/release process, based on a thread I started here.

This page may possibly be useful to you in understanding the details of this stuff:

https://docs.fedoraproject.org/en-US/quick-docs/repositories/

There are three things to keep in mind, broadly speaking: the Bodhi 'update' process, Koji tags, and the compose process.

When we do an F31 compose what we're basically doing is taking all the packages that have the tag 'f31' in Koji and producing some repositories and some 'deliverables' (i.e. images, basically) from them, all bundled up in this thing called a 'compose'.

If that compose is a nightly compose, and it's successful, the symlink you linked above will point to it. Also, its contents will be synced out to https://dl.fedoraproject.org/pub/fedora/linux/development/31/ … which is where the 'fedora' repository on an installed system goes looking for stuff.

How packages get that 'f31' tag is (after the Bodhi enablement point) via Bodhi. A packager does a build in Koji first; at that point it doesn't get the 'f31' tag. Then they submit an update to Bodhi, at which point the build gets the 'f31-updates-testing' tag and is included in the next f31 updates-testing compose, and goes to the updates-testing repository. Once the update meets the requirements in the updates policy and is “submitted for stable” (either manually or automatically), it is given the 'f31' tag - when Bodhi “pushes an update to stable”, what it really *does* is apply the 'f31' tag to it. (This is during the pre-release Branched phase, note; after release it works a bit differently). So once an update has been 'pushed stable', it gets the 'f31' tag; the next time a compose is run that package will be installed, and if that compose is successful, that package will appear (soon afterwards) in the 'fedora' repository for an installed Fedora 31 system.

When we do what's called a 'candidate' compose - the ones that are candidates to be released as Beta or Final - we do more or less the same thing, though the compose gets a slightly different compose ID and gets a 'label' (like Beta-1.1 or RC-1.2) which nightly composes don't get. But for a 'candidate' compose we may include some packages that are only in updates-testing at the time, if those packages fix blocker or freeze exception bugs. So 'candidate' composes may have a few packages that a 'nightly' compose run on the same date do not have.

However, once we sign off on a candidate compose to be released, we then push any such additional packages it contained to stable as soon as possible. We also push them stable a day or two *before* we push any later updates stable. So as a practical matter, for both Beta and Final there are usually two or three nightly composes shortly after a candidate compose is accepted for release that are effectively identical to the candidate compose. So to answer your initial question - from a day or two after the Final release candidate is signed off, the compose you find at the location you linked will be practically identical to it. It won't be *literally* identical, but it should contain all the same packages.

Nightly Branched composes appear here: https://kojipkgs.fedoraproject.org/compose/branched/

and are run automatically every day (occasionally we manually fire respins). The most recent successful one is automatically symlinked to the URL you gave shortly after it completes.

Candidate composes will appear here: https://kojipkgs.fedoraproject.org/compose/31 (that location doesn't exist yet and won't until the first Beta candidate compose is requested). They are done on request (requests made by the QA team to release engineering, per https://fedoraproject.org/wiki/QA:SOP_compose_request ).

[A beta] Freeze doesn't mean anything in particular in terms of composes (i.e. ISOs). Nightly composes happen every day after branching, regardless of anything else. What the freeze means is that the usual rules for updates to be 'pushed stable' (i.e. given the f31 tag and included automatically in subsequent nightly and candidate composes) are suspended until the Beta release; instead updates can only be 'pushed stable' manually during the freeze period, and *only* updates which fix blocker or freeze exception bugs will be pushed stable. That process again is handled by QA filing requests for releng: I filed the first one for the F31 Beta freeze earlier today, here: https://pagure.io/releng/issue/8702

Pending updates that don't fix blocker or FE bugs just get to sit in updates-testing during freezes. Once the Beta release candidate is signed off, a day or two later we 'unfreeze' and all queued updates that were submitted for stable but not pushed stable due to the freeze get pushed stable in one big dump.

One thing to keep in mind during all this is that if you have an

• installed F31 system*, the updates-testing repository will be enabled by default, which means that when you update the system you won't only get packages that have been 'pushed stable' and are showing up in the composes - you'll get all packages that have been submitted to Bodhi, even before they are 'pushed stable'. Your installed system will usually be 'ahead of' the nightly composes and even the candidate composes. If you want to stay in sync with what's been 'pushed stable' you can disable the updates-testing repository. The reason we do this is essentially that this whole process relies on people to test the packages that are submitted as updates and provide feedback to help decide whether or not they should be 'pushed stable'; if you install a pre-release we assume you're basically volunteering to help testing, so you get updates-testing enabled.

Hope that made things more rather than less clear! Do ask if you have any further questions.