Fix the xrefs to other components

This commit is contained in:
Ben Cotton 2021-07-08 09:56:13 -04:00
commit ab82735fe4
2 changed files with 10 additions and 10 deletions

View file

@ -2,7 +2,7 @@
Branched is the name given to a version of Fedora that has "branched" from the rolling xref:releases/rawhide.adoc[Rawhide] tree and will become the next stable Fedora release.
It consists of a http://download.fedoraproject.org/pub/fedora/linux/development/[Fedora development release tree] named after the Fedora release it will become.
It contains builds of all Fedora packages updated by maintainers with the goal of stabilizing before release and fixing any release xref:program_management:changes_policy.adoc].
It contains builds of all Fedora packages updated by maintainers with the goal of stabilizing before release and fixing any release xref:program_management::changes_policy.adoc[Changes].
Full nightly composes are also produced each night when a Branched release exists, usually containing all images and installer trees (minus any which fail to build).
== Goals
@ -59,7 +59,7 @@ Therefore, it's usually not worth filing a bug for broken dependencies unless th
== Producing Branched
The Branched compose runs every day starting at 09:15UTC.
All branched package builds at that time that are marked as xref:quick-docs:repositories.adoc[_stable_] are included in the compose attempt.
All branched package builds at that time that are marked as xref:quick-docs::repositories.adoc[_stable_] are included in the compose attempt.
If any release-blocking image fails to build as part of the compose, the compose is considered to have failed.
If the compose completes successfully, a set of automated tests intended to check its compliance with the https://fedoraproject.org/wiki/Basic_Release_Criteria[Basic Release Criteria] are run.
If these tests pass, the compose will be synced out to the mirror system.
@ -69,8 +69,8 @@ You can find a local mirror on the http://mirrors.fedoraproject.org/publiclist/F
Compose time varies depending on number of changes but is typically between 5 and 8 hours.
Branched is subject to various policies during its life cycle.
For most of its existence, it is subject to the xref:fesco:Updates_Policy.adoc[Updates Policy] and package updates for it are gated through the https://fedoraproject.org/wiki/Bodhi[Bodhi] package review process.
At various points of the xref:lifecycle.adoc[Fedora Release Life Cycle], other freezes, policies and requirements come into effect, including the https://fedoraproject.org/wiki/Software_String_Freeze_Policy[Software String Freeze Policy], the https://fedoraproject.org/wiki/Milestone_freezes[freezes], and the xref:program_management:chages_policy.adoc#change_process_milestones[Change freezes].
For most of its existence, it is subject to the xref:fesco::Updates_Policy.adoc[Updates Policy] and package updates for it are gated through the https://fedoraproject.org/wiki/Bodhi[Bodhi] package review process.
At various points of the xref:lifecycle.adoc[Fedora Release Life Cycle], other freezes, policies and requirements come into effect, including the https://fedoraproject.org/wiki/Software_String_Freeze_Policy[Software String Freeze Policy], the https://fedoraproject.org/wiki/Milestone_freezes[freezes], and the xref:program_management::chages_policy.adoc#change_process_milestones[Change freezes].
See all the above links for more details on exactly what changes may occur in the Branched tree under what conditions at what times.
Composes are done using the 'mash' and https://pagure.io/pungi[Pungi] tools called from a script maintained by Fedora Release Engineering.
@ -80,9 +80,9 @@ A report for each Branched compose is sent to to the https://lists.fedoraproject
This report contains output from the https://pagure.io/compose-utils[compose-changelog] tool from the previous compose as well as a broken dependency report for packages with broken dependencies.
Additionally, private email is sent to maintainers with packages containing broken dependencies.
Package maintainers should read and follow the xref:fesco:Updates_Policy.adoc[Branched release updates policy] for building any packages in Branched.
Package maintainers should read and follow the xref:fesco::Updates_Policy.adoc[Branched release updates policy] for building any packages in Branched.
Until the xref:fesco:Updates_Policy.adoc#updates-testing-activation[Bodhi enabling point], you cannot expect all packages in the Branched tree to be signed.
Until the xref:fesco::Updates_Policy.adoc#updates-testing-activation[Bodhi enabling point], you cannot expect all packages in the Branched tree to be signed.
To use Branched at these times, GPG signature checking in your package management tool must be disabled.
== Questions and Answers ==

View file

@ -1,7 +1,7 @@
= Rawhide
"Rawhide" is the name given to the current development version of Fedora Linux.
It consists of a xref:quick-docs:repositories.adoc[package repository] called "rawhide" and contains the latest build of all Fedora Linux packages updated on a daily basis.
It consists of a xref:quick-docs::repositories.adoc[package repository] called "rawhide" and contains the latest build of all Fedora Linux packages updated on a daily basis.
Each day, the build system attempts to create a full set of deliverables (installation images and so on), and all that compose successfully are included in the Rawhide tree for that day.
Rawhide is sometimes called "development" or "main" (as it's the "main" branch in package git repositories).
@ -82,9 +82,9 @@ A report for each Rawhide compose is sent to to the https://lists.fedoraproject.
This report contains output from the repodiff tool from the previous compose as well as a broken dependency report for packages with broken dependencies.
Additionally, private email is sent to maintainers with packages containing broken dependencies.
Package maintainers should read and follow the xref:fesco:Updates_Policy.adoc#rawhide[Rawhide updates policy] for building any packages in Rawhide.
Package maintainers should read and follow the xref:fesco::Updates_Policy.adoc#rawhide[Rawhide updates policy] for building any packages in Rawhide.
If needed and approved by xref:fesco:index.adoc[FESCo], mass rebuilds are done by Release Engineering in Rawhide a month or so before the next release branches from it.
If needed and approved by xref:fesco::index.adoc[FESCo], mass rebuilds are done by Release Engineering in Rawhide a month or so before the next release branches from it.
Typically these are done for a global change over all packages such as a new gcc release, or rpm package format.
== Questions and Answers
@ -140,7 +140,7 @@ One common use case is to switch your system to Branched right after it is creat
In this case, the sooner you do it (after branching), the safer and easier it is—the difference between systems is minimal at that point.
Downgrading after a long time, or downgrading to a stable release (which is completely different from Rawhide) will be more problematic.
You can (attempt to) downgrade to Branched or a stable release using xref:quick-docs:dnf-system-upgrade.adoc[DNF system upgrade] (the same approach as for upgrades).
You can (attempt to) downgrade to Branched or a stable release using xref:quick-docs::dnf-system-upgrade.adoc[DNF system upgrade] (the same approach as for upgrades).
However, because Rawhide uses a different set of system repositories, you need to explicitly disable those during the download phase, and explicitly enable the set or repositories used on non-Rawhide systems.
So the download command would look like this (this will disable and enable the correct repositories, and if you have some additional (including third-party) repositories installed, it will keep them enabled or disabled as they are currently; replace `NN` with the target release number): `sudo dnf system-upgrade download --releasever=NN --disablerepo='rawhide,rawhide-modular' --enablerepo='fedora,fedora-modular,updates,updates-modular'`