Apertis release process: add recommendation to update the dashboard

content/guides/maintenance/apertis_release_process.md

@@ -54,6 +54,7 @@ As a high level overview, these are the steps to be executed during the release
 * Check available [disk space on OBS Server](#obs-disk-space)
 * Perform [Release Branching](#release-branching)
 * [Publish Release](#publish-release)
+* Update channels for [Apertis packages Dashboard](#dashboard-update)
 
 ## Release Branching
 
@@ -144,6 +145,7 @@ A Stable Point Release includes:
 * [Publish Release Candidate](#publish-release-candidate) (RC1) images and announce hard code freeze
 * RC images validation (QA)
 * [Publish Release](#publish-release)
+* Update channels for [Apertis packages Dashboard](#dashboard-update)
 
 Several of the steps above were already described in the previous section, the following section will describe
 those steps specific for stable point releases.
@@ -472,3 +474,15 @@ obsolete *Beta* and *Preview* distribution releases, like: `v2019dev0`, `v2019pr
   Deleting vanished identifier 'u|v2019pre|proprietary|amd64'.
   Deleting vanished identifier 'u|v2019pre|proprietary|armhf'.
   ```
+
+## Dashboard update
+
+At the end of the release process, it's necessary to update the channels tracked
+by the [Apertis packages Dashboard](https://infrastructure.pages.apertis.org/dashboard/).
+This ensures that we focus on current releases.
+As soon as we publish a new release, it can be marked as closed (with `status: closed`)
+in the [channels.yaml](https://gitlab.apertis.org/infrastructure/dashboard/-/blob/master/data/channels.yaml),
+this will hide some reports which are no longer of interest.
+Two weeks after a release, it can be completely removed from this channels file.
+This period allows us to keep an eye on a release after its publication in case
+of potential issues while downstream projects are synchronizing.