This updates the branch time instructions to include setting an EOL for Branched. With https://pagure.io/fedora-infra/toddlers/pull-request/326 we no longer need to avoid doing it, and we should set one at branch time to be in sync with the schedule and fedora-release. We also update the instructions at Final release time to be more explicit about what the EOL should be set to, syncing it with the schedule and fedora-release, and also checking the EOLs for other releases. We drop the reference to `adjust-eol-all.py` because that was for PDC. Signed-off-by: Adam Williamson <awilliam@redhat.com>
136 lines
5.3 KiB
Text
136 lines
5.3 KiB
Text
include::_partials/attributes.adoc[]
|
|
|
|
= Fedora Final Release
|
|
|
|
== Koji changes
|
|
|
|
[source,subs="attributes+"]
|
|
....
|
|
$ koji edit-tag --lock f{branched}
|
|
....
|
|
|
|
== Bodhi Changes
|
|
|
|
Set the bodhi release to `current`
|
|
[source,subs="attributes+"]
|
|
....
|
|
$ bodhi releases edit --name F{branched} --state current
|
|
$ bodhi releases edit --name F{branched}F --state current
|
|
....
|
|
|
|
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
|
|
....
|
|
|
|
Set EOL of oldest release to correct date: four weeks after the official release date of {branched}.
|
|
[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
|
|
....
|
|
|
|
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.
|
|
|
|
== 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.
|
|
|
|
== Ansible Changes
|
|
|
|
=== Update releng roles updates
|
|
|
|
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/00-FedoraCycleNumber.yaml[FedoraCycleNumber] to {branched}.
|
|
|
|
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/FedoraBranchedBodhi.yaml[FedoraBranchedBodhi] to current.
|
|
|
|
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/FedoraPreviousPrevious.yaml[FedoraPreviousPrevious] to True.
|
|
|
|
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/FedoraBranched.yaml[FedoraBranched] to False.
|
|
|
|
. Set https://pagure.io/fedora-infra/ansible/blob/main/f/vars/all/Frozen.yaml[NextReleaseFrozen] to False.
|
|
|
|
Now run the relevant playbooks:
|
|
|
|
....
|
|
$ sudo rbac-playbook groups/koji-hub.yml
|
|
$ sudo rbac-playbook groups/releng-compose.yml
|
|
$ 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
|
|
....
|
|
|
|
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],
|
|
though note it is somewhat old and includes some things that are no longer needed, and leaves out some that should be done.
|
|
|
|
== Stage Final Release for Mirrors
|
|
|
|
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.
|
|
+
|
|
[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
|
|
|
|
[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.
|
|
====
|
|
|
|
== 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)
|
|
|
|
== Verification
|
|
|
|
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.
|
|
|
|
Some things to check for:
|
|
. are the CHECKSUM files signed?
|
|
. are the spins/labs present?
|
|
|
|
== 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>`
|
|
|
|
Once enough mirrors have picked up the files in the release directory,
|
|
run the following playbook from batcave to change the paths in
|
|
MirrorManager:
|
|
|
|
[source,subs="attributes+"]
|
|
....
|
|
$ rbac-playbook -v /srv/web/infra/ansible/playbooks/manual/mirrormanager/move-devel-to-release.yml --extra-vars="version='42'"
|
|
....
|