2023-03-03 11:52:29 +01:00
include::_partials/attributes.adoc[]
2023-08-16 13:13:26 +02:00
= Fedora Final Release
2023-02-28 14:50:03 +01:00
2023-08-16 13:13:26 +02:00
== Koji changes
2023-03-01 15:57:09 +01:00
2023-03-08 15:39:31 +01:00
[source,subs="attributes+"]
2023-03-01 15:57:09 +01:00
....
2023-03-08 15:39:31 +01:00
$ koji edit-tag --lock f{branched}
2023-03-01 15:57:09 +01:00
....
2023-08-16 13:13:26 +02:00
== Bodhi Changes
2023-03-01 15:57:09 +01:00
Set the bodhi release to `current`
2023-03-08 15:39:31 +01:00
[source,subs="attributes+"]
2023-03-01 15:57:09 +01:00
....
2023-03-08 15:39:31 +01:00
$ bodhi releases edit --name F{branched} --state current
2024-11-04 11:34:56 -08:00
$ bodhi releases edit --name F{branched}F --state current
2023-03-01 15:57:09 +01:00
....
2023-09-05 10:30:50 -07:00
Set the bodhi stable tag to point to updates instead of base repo
[source,subs="attributes+"]
....
$ bodhi releases edit --name F{branched} --stable-tag f{branched}-updates
....
2025-02-28 12:48:29 -08:00
Set EOL of oldest release to correct date: four weeks after the official release date of {branched}.
2023-04-20 11:43:45 +02:00
[source,subs="attributes+"]
....
$ bodhi releases edit --name F{old_release} --eol YYYY-MM-DD
$ bodhi releases edit --name F{old_release}C --eol YYYY-MM-DD
$ bodhi releases edit --name F{old_release}F --eol YYYY-MM-DD
....
2025-02-28 12:48:29 -08:00
If this date is different from the one in the https://fedorapeople.org/groups/schedule/f-{old_release}/f-{old_release}-key-tasks.html[Fedora schedule],
ask the program manager to update the date in the schedule.
If it is different from the one in F{old_release}'s `/etc/os-release`, https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format&component=fedora-release&version=40[file a bug against fedora-release] asking for it to be updated.
You may also wish to check the current EOL estimates for other releases on Bodhi, the schedule, and fedora-release,
and make sure they are in sync and sensible.
2024-10-29 13:44:44 -07:00
== Atomic desktops changes
Run the releng scripts/update_ostree_refs.sh on a compose machine with /mnt/koji/ mounted.
$ scripts/update_ostree_refs.sh {branched}
This updates the refs for Atomic desktops to have users follow updates
for the new release rather than being stuck on the GA compose forever.
2023-11-03 14:48:44 +05:30
== Ansible Changes
=== Update releng roles updates
2024-11-27 10:01:00 -08:00
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/00-FedoraCycleNumber.yaml[FedoraCycleNumber] to {branched}.
2023-11-03 14:48:44 +05:30
2024-11-27 10:01:00 -08:00
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/FedoraBranchedBodhi.yaml[FedoraBranchedBodhi] to current.
2023-11-03 14:48:44 +05:30
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/FedoraPreviousPrevious.yaml[FedoraPreviousPrevious] to True.
2024-11-27 10:01:00 -08:00
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/FedoraBranched.yaml[FedoraBranched] to False.
2023-11-03 14:48:44 +05:30
2025-02-13 12:16:43 -08:00
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/Frozen.yaml[NextReleaseFrozen] to False.
Now run the relevant playbooks:
2024-04-24 20:46:21 +02:00
....
2025-02-13 12:16:43 -08:00
$ sudo rbac-playbook groups/koji-hub.yml
2024-11-27 10:01:00 -08:00
$ sudo rbac-playbook groups/releng-compose.yml
2025-02-13 12:16:43 -08:00
$ sudo rbac-playbook openshift-apps/bodhi.yml
$ sudo rbac-playbook groups/bodhi-backend.yml
$ sudo rbac-playbook openshift-apps/greenwave.yml
$ sudo rbac-playbook groups/openqa.yml -t testcase_stats
2024-04-24 20:46:21 +02:00
....
2025-02-13 12:16:43 -08:00
If you do not have permissions to run a playbook, ask a sysadmin-main member for help.
A sysadmin-qa member can run the openQA playbook.
For reference, see the https://pagure.io/fedora-infra/ansible/c/7e501dcb9432885c9ef10e78c0418b0d40c85061[Fedora 41 release PR],
2024-11-27 10:01:00 -08:00
though note it is somewhat old and includes some things that are no longer needed, and leaves out some that should be done.
2023-08-16 13:13:26 +02:00
== Stage Final Release for Mirrors
2023-03-08 15:39:31 +01:00
2023-11-03 14:48:44 +05:30
To prepare for running the staging script, make sure you have the following information:
. Release Version: This is the numerical version number of the release, for example, {branched}.
. ComposeID: The ID associated with the Compose, such as "Fedora-{branched}-20160614.0".
. Label: The label used for the location in stage, for example, "Compsoe label for the location in stage 39_RC-1.2."
. Key: The name of the release key, which can be "fedora-{branched}" or "fedora-{branched}-secondary," as examples.
. Prerelease: Set this to 0 or 1 to determine if the release should be placed in a testing environment or not.
. Arch (Optional): For secondary architectures, this parameter can be used to make changes to some internal locations.
2023-03-08 15:39:31 +01:00
+
[source,subs="attributes+"]
....
$ scripts/stage-release.sh {branched} Fedora-{branched}-20160614.0 {branched}_RC-1.2 fedora-{branched} 0
....
. Sync the release to the Red Hat internal archive following internally
documented
2023-11-03 07:50:04 +00:00
[NOTE]
====
Make sure to grab the directory size usage numbers which is used to send
an email to [.title-ref]#mirror-admin@lists.fedoraproject.org# list.
====
2023-12-05 17:34:26 +00:00
== Make sure there are no tagging leftovers from bodhi
Sometimes builds are not properly tagged during the freeze process.
Make sure all builds are properly tagged, for more info about the [issue](https://pagure.io/releng/issue/11775)
2023-08-16 13:13:26 +02:00
== Verification
2023-03-08 15:39:31 +01:00
Verification is somewhat difficult as one cannot look at the content via
the web server due to permissions. Typically we ask somebody from the
Infrastructure team to give the tree a second set of eyes.
2024-04-29 14:59:21 +05:30
2024-11-04 11:34:56 -08:00
Some things to check for:
. are the CHECKSUM files signed?
. are the spins/labs present?
2024-04-29 14:59:21 +05:30
== Post Release
=== One Week After the Release
In the first week after the release MirrorManager still uses the files
at `fedora/linux/development/<version>` and not at
`fedora/linux/releases/<version>`
2024-08-06 09:07:01 +02:00
Once enough mirrors have picked up the files in the release directory,
run the following playbook from batcave to change the paths in
2024-04-29 14:59:21 +05:30
MirrorManager:
[source,subs="attributes+"]
....
2024-08-06 09:07:01 +02:00
$ rbac-playbook -v /srv/web/infra/ansible/playbooks/manual/mirrormanager/move-devel-to-release.yml --extra-vars="version='42'"
2024-04-29 14:59:21 +05:30
....