fedora_releases_koji_bodhi [Doku Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Overview =====

First pass at describing the Fedora update/upgrade/release process, based on a thread I started [[https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/QYTMEEOT233NHPYNVETX5QXTTOCS3RQQ/|here]].

===== Adam's explanation in that thread =====

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.