architecture/hlfs/factory-staging.md

@@ -19,3 +19,49 @@ For example, if a core library like `openssl` (part of Ring0) is updated, all ot
 - **Note on Performance:** To avoid slowing down Gitea, packages in the repository will be sharded into subfolders based on alphabetical grouping (e.g., folders for `a*` packages, `python-*` packages, etc.).
 
 - To replicate the Factory team's current use of the `bootstrap_copy` aggregate in the new dynamic `:PR` staging projects, a new intermediate project will be created. This project will aggregate packages from Ring0, and will then be used as the source for the `bootstrap_copy` aggregate within each `:PR` project.
+
+## Current Setup To Review
+
+### Build Staging Definition
+
+The main configuration file is read from (staging.config)[https://src.opensuse.org/openSUSE/Factory/src/branch/main/staging.config].
+
+The `ObsProject` is where the Factory git (the git providing this file) is build. Currently only a few selected packages are
+referenced there.
+
+The `StagingProject` is the root of all staging projects. This includes the templates and also the temporary created projects
+for test builds.
+
+The `QA` area currenlty only defines two projects. Both of them get created when the referenced Label is set on a pull request.
+
+The staging bot is copying the project meta and checks for project links or repository pathes which may need to get adapted.
+For example the `openSUSE:Factory:PullRequest:1-MinimalX` template is copied as `openSUSE:Factory:PullRequest:PR_NUMBER:MinimalX`. In addition the project link pointing to `openSUSE:Factory:PullRequest` gets converted to `openSUSE:Factory:PullRequest:PR_NUMBER`. Also the `images` path which builds against the `standard` path of same project gets the new project name. Therefore the images and products inside of `images` are using the binaries built in the `standard` repository of the very same pull request project.
+
+The `openSUSE:Factory:PullRequest:1-MinimalX` template is currently not git based. This allows us to
+
+- use the existing production `openSUSE:Factory:Rings:1-MinimalX` and `openSUSE:Factory:Rings:0-Bootstrap` sources
+
+- also an overlay of the package sources already available in `openSUSE:Factory:PullRequest:PR_NUMBER` to use them for a full bootstrap.
+
+The `openSUSE:Factory:PullRequest:0-Base` template is already git based. However, it only provides a single aggregate file. The repository is set to `rebuild=local`. This has the effect that the base binaries are only take once during project creation for a stable snapshot of binaries. This decuples the pull request projects and avoids blocked states or unwanted rebuilds. However, in case the release manager wants to update the base binaries, he can trigger a rebuild of the aggregate. This QA project is also always created when the MinimalX QA project is wanted. Therefore it is based on the same gitea Label. It needs to be before the MinimalX definition in the `staging.config` file, because the MinimalX is referencing it. So the setup order matters.
+
+## Further Staging Options
+
+### Full Rebuild
+
+We could add a template (project meta and gitea label) which rebuilds entire factory. That would be very resource consuming,
+but may be important eg. on bigger gcc or rpm updates.
+
+### Dependend Rebuild
+
+We could have a template which only rebuilds all packages depending on a certain package. This can be useful to easily test builds which are higher on the dependency stack. For example all golang or all KDE packages.
+
+### Specific QA images
+
+For example kiwi appliance images or docker containers for public cloud or kubernetes tests
+
+### Non-Goals
+
+Individual grouping of packages should *not* be done via templates. Instead the release manager should group the package
+pull requests into a single factory pull request.
+