rebasing: Update guide

After the initial work in the rebase, update the documentation to show the
approach taken.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>

content/guides/maintenance/rebasing.md

@@ -22,7 +22,7 @@ more information about this policy.
 
 The following terms will be used here:
 
-- `CUR_DEV_RELEASE`: The existing Apertis release on which the new release will
+- `CUR_DEV_RELEASE`: The current Apertis release on which the new release will
   be based.
 - `NEW_DEV_RELEASE`: The new Apertis development release that we are creating
   during the rebasing process.
@@ -37,8 +37,18 @@ Q1.
 
 ## A. Test Rebase Workflow
 
-1. Follow the rebase plan, but with a limited set of packages from target using
-   `NEW_DEV_RELEASE` set to `rebase-test`.
+1. Follow the rebase plan, but with a limited set of packages from target, forking
+   them in a new namespace, such as `pkg-rebase-trixie`.
+1. Create a MR `wip/xxx/rebase-preparation` in `apertis-docker-images` to draft the changes to be used during
+   the rebase.
+1. Tweak the `package-source-builder` dockerfile in the `NEW_DEV_RELEASE`
+   release to enable Debian `NEW_DEBIAN_RELEASE`
+1. Enable apertis `CUR_DEV_RELEASE` repositories in dockerfile, to allow
+   the installation of Apertis specific packages, such as `apertis-dev-tools`
+1. Temporarily disable other docker images as they won't be needed
+1. Create new OBS projects for `pkg-rebase-trixie`
+1. Disable publish of `pkg-rebase-trixie` on OBS projects
+1. Add `NEW_DEBIAN_RELEASE` DoD on `pkg-rebase-trixie` OBS repositories
 1. Check that pipelines run as expected
 1. Check that the scripts used to check status work as expected
 
@@ -47,7 +57,7 @@ It is not required to merge all the changes, focus on ensuring that the
 workflow is working as expected.
 {{% /notice %}}
 
-## B. Test Debian Sources
+## B. Prepare package lists
 
 If sufficient time is available early in Q1, it is advantageous to ensure that
 we have a relatively accurate seed list and have already imported new
@@ -57,10 +67,8 @@ flagged by OBS. The aim here is to reduce the time required when rebasing.
 
 1. Use [germinate](https://gitlab.apertis.org/infrastructure/germinate) to
    generate seeds for `NEW_DEBIAN_RELEASE`.
-1. Compare "existing-packages" lists generated for `NEW_DEBIAN_RELEASE` with
-   the list of packages in the current Apertis release. Review differences and
-   update the new seed list as required.
-1. Review packages listed in "new-packages" lists for addition to Apertis
+1. Follow the instructions in the repository to update the seed list and blacklist
+   to allow smoother rebase process with fewer iterations.
 
 # Preparing for Rebase
 
@@ -70,20 +78,16 @@ During the rebase `NEW_DEV_RELEASE` will be unstable as many packages will be
 updated and images will not be generated. To allow development work during this
 time, `CUR_DEV_RELEASE` will be used as development branch. For that reason,
 after `CUR_DEV_RELEASE` freeze ends, it will be used for development.
+
 {{% notice note %}}
 For repositories that diverge during the rebase cycle, after the rebase is
 completed, changes will need forward porting to `NEW_DEV_RELEASE`.
 {{% /notice %}}
 
-
 ## D. Prepare Infrastructure
 
-1. Create `NEW_DEV_RELEASE` branch for `apertis-docker-images`
-1. Tweak the `package-source-builder` dockerfile in the `NEW_DEV_RELEASE`
-   release to enable Debian `NEW_DEBIAN_RELEASE`
-1. Enable apertis `CUR_DEV_RELEASE` repositories in dockerfile, to allow
-   the installation of Apertis specific packages, such as `apertis-dev-tools`
-1. Temporarily disable other docker images as they won't be needed
+1. Merge the changes in `wip/xxx/rebase-preparation` into `NEW_DEV_RELEASE` branch
+   for `apertis-docker-images`
 1. Create new OBS projects for `NEW_DEV_RELEASE`
 1. Disable publish of `NEW_DEV_RELEASE` on OBS projects
 1. Add `NEW_DEBIAN_RELEASE` DoD on `NEW_DEV_RELEASE` OBS repositories
@@ -125,10 +129,10 @@ It is better to process the list of packages in batches, starting with a small n
    ```
 
 1. Trigger the pipeline on the `debian/NEW_DEBIAN_RELEASE` branches using the
-   [`trigger-pipeline`](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/gitlab/trigger-pipeline)
+   `trigger-pipeline` function from [manage-repo]](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/manage-repo)
    script:
    ```
-   $ ./trigger-pipeline ${pkg} debian/${NEW_DEBIAN_RELEASE}
+   $ ./release-scripts/manage-repo trigger-pipeline ${pkg} debian/${NEW_DEBIAN_RELEASE}
    ```
    This will trigger a chain of pipelines that will sync with the branch with
    the required Debian release and attempt to merge with the `NEW_DEV_RELEASE`
@@ -152,7 +156,7 @@ should be checked in the following order:
 - Other packages, such as those in `development` and `sdk`.
 
 The
-[analise-rebases.py](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/analyse-rebases.py)
+[analyse-rebases.py](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/rebase-scripts/analyse-rebases.py)
 script can be used to aid with this process.
 
 There will be different scenarios depending on the package:
@@ -205,8 +209,8 @@ Keep track of delta introduced as this will need to be documented, rectified or
    [analyse-missing.py](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/analyse-missing-packages.py)
 1. Check if all build statuses are green on OBS
 1. Check that OBS is NOT using Debian DoD to build packages using the
-   [`check-for-dod`](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/release-scripts/check-for-dod) script.
-1. Drop Bookworm DoD repositories from OBS
+   [`check-for-dod`](https://gitlab.apertis.org/infrastructure/apertis-infrastructure/-/blob/main/rebase-scripts/check-for-dod) script.
+1. Drop Debian DoD repositories from OBS
 1. Fix any leftover cracks:
    * New package imports
    * Build dependency trimming