Differences

This shows you the differences between two versions of the page.

--- fedora_releases_koji_bodhi [2019/08/28 11:01] – rpjday
+++ fedora_releases_koji_bodhi [2019/08/28 11:04] (current) – rpjday
@@ Line 3: / Line 3: @@
 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 =====
+===== Adam's explanation in that thread =====
 This page may possibly be useful to you in understanding the details of
@@ Line 24: / Line 24: @@
 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.