branching: update post CI manual steps

This MR aligns the post CI manual steps with the actual practice.

On the other hand, all of these steps are now part of the misc-updates stage, so no longer post CI. I think deleting the whole paragraph would be less confusing.

content/guides/maintenance/apertis_release_process.md

@@ -108,21 +108,15 @@ has not been updated accordingly. The `rulez.yaml` file needs to be updated, the
 the pipeline can be re-triggered.
 {{% /notice %}}
 
-### Post CI Manual Steps
+Towards the end of the branching pipeline, a certain set of manual steps need to be performed, which are outlined below.
+All these steps are grouped in a stage called `misc-updates`.
 
-After the completion of the **Release Branching** CI Jobs, a certain set of manual steps need to be performed, which are outlined below.
-
-* Add a directory for the release to the LAVA NFS path at: `/srv/images/public/lava/nfs/` on host images.apertis.org. The LAVA test jobs pick the kernel and initrd image from the release's directory path. Refer to the README for details.
 * Instantiate a *new timer to rotate images* for the new release (eg. On host `aurora`, run command `systemctl enable --now rotate-images@v2024.timer`).
-* Update the [ci-package-builder](https://gitlab.apertis.org/infrastructure/ci-package-builder/) to target the next release.
-* Update the [gitlab-rulez recipe](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/gitlab-scripts/rulez.yaml) to point to the new development release.
-  * Set the default development branch for all git projects.
-  * Set the protection settings onto all `apertis/*` branches, which were unprotected in the initial release steps.
-* Update the [dashboard](https://gitlab.apertis.org/infrastructure/dashboard)'s channels to track the new release.
 * Trigger a build pipeline on the newly created branch of [base-files](https://gitlab.apertis.org/pkg/base-files/) package, after the new docker images have been built.
   * This step should automatically update the release specific attributes in the new package and auto propose the changes through a new merge request.
   * Validate the newly created pipeline ensuring that it generates the right set of changes with respect to the new release.
   * Validate the new package is built proper and pushed to OBS and the APT repositories.
+* Update the [dashboard](https://gitlab.apertis.org/infrastructure/dashboard)'s channels to track the new release.
 
 # Stable Point Release