Improve workflow guide

Start shifting the workflow guid towards a general high level overview of
the Apertis workflow. Add images to make the process easier to understand.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

content/architecture/workflow-guide.md

@@ -5,36 +5,65 @@ weight = 100
 date = "2021-04-29"
 +++
 
-Apertis is built on top of Debian `deb` packages for their high quality and
-modularity.  All package source code is stored in
-[GitLab](https://gitlab.apertis.org/), where they are grouped into the
-following categories:
+Apertis is primarily built from Debian source packages utilising optimised,
+automated workflows based on the processes used by Debian. The Debian sources
+were selected due to their high quality, modularity, having no reliance on a
+single vendor and the large number of components already packaged.
+
+Apertis utilises the tools provided by the Debian community, combining
+these with other tools, such as [GitLab](https://about.gitlab.com/) and the
+[Open Build Server](https://openbuildservice.org/) (OBS) to create a more
+automated, optimised workflow.
+
+![](/images/apertis-functional-view.svg)
+
+The source code and packaging metadata for all Apertis packages are expected to
+be stored in the [Apertis GitLab instance](https://gitlab.apertis.org/), with
+the shared components (i.e. those that are not project specific) being stored
+under the [`pkg` group](https://gitlab.apertis.org/pkg). These components are
+further split into the following categories:
 
 - `target`: packages intended for use in product images
-- `development`: additional packages needed to build `target` and development
-  tools
-- `hmi`: packages for the current reference HMI on top of `target`
-- `sdk`: packages to build the SDK virtual machine recommended for development
-
-In case of common interests new packages can easily be introduce in the
-relevant GitLab groups. It is also possible to create additional projects in
-GitLab for e.g.  product specific software packages or product specific
-modifications that build on top of the common baselines but aren't suitable for
-more general inclusion.
-
-Automation implemented via GitLab CI/CD pipelines is provided to perform sanity
-check builds of the packages. CI/CD pipelines are also implemented to upload
-changes to the
-[Open Build Service -(OBS) instance](https://build.collabora.com) provided by
-Collabora.
+- `development`: additional packages needed to build `target` packages and
+  development tools
+- `hmi`: packages for the current reference user interface (or Human Machine
+  Interface, often abbreviated to HMI) which can be use on top of `target`
+- `sdk`: packages to build the SDK virtual machine, which is recommended for
+  development
 
-OBS takes care of automatically building the package sources for all the
-configured architectures (`x86_64`, `armv7l`, `aarch64`) and publishes the
-results as signed APT repositories. Each package is built in a closed,
-well-defined environment where OBS automatically installs all the build tools
-and resolves dependencies from a clean state using the packages it has built
-already: if any dependency is missing the build fails and the developer is
-notified. Build failures are reported back into the relevant GitLab pipeline.
+The separation of packages into these categories allows the Apertis project to
+maintain different
+[licensing expectations]({{< ref "license-expectations.md#apertis-licensing-expectations" >}})
+for the various component use cases. Where common interests in a component
+exist, these can be added into the `pkg` group. It is also possible to create
+additional projects in GitLab for project specific software packages or project
+specific modifications to an existing component that isn't suitable for more
+general inclusion.
+
+{{% notice info %}}
+Components can be added to Apertis using the
+[contributions process]({{< ref "contributions.md#adding-components-to-apertis" >}}).
+
+The [packaging workflow guide]({{< ref "apertis_packaging_guide.md" >}})
+provides more information on the practical steps required to achieve this and
+the [component layout guide]({{< ref "gitlab-based_packaging_workflow.md" >}})
+provides information regarding the layout of a component repository.
+{{% /notice %}}
+
+Automation is implemented via GitLab CI/CD pipelines that performs sanity
+check builds of the packages. Further CI/CD pipelines are provided to upload
+changes to the
+[OBS instance](https://build.collabora.com) (provided by Collabora) which
+takes care of automatically building the package sources for all the
+configured architectures (`x86_64`, `armv7l`, `aarch64`) and publishing the
+resulting binary packages in signed APT repositories. Each package is built in
+a closed, well-defined environment where OBS automatically installs all the
+build tools and resolves dependencies from a clean state using the packages it
+has built already: if any dependency is missing, the build fails. Any build
+failures are reported back to the relevant GitLab pipeline and to the
+appropriate developers.
+
+![Binary package generation from source change](/images/workflow_binary-package-generation.svg)
 
 Most of the package sources get automatically updated from the latest Debian
 Stable release or have been manually picked from a later Debian release or
@@ -46,14 +75,16 @@ bug fixes and security fixes with the efforts done by the wider Debian
 community.
 
 After OBS has finished building a package, the results get published in a
-Debian package repository. The open-source packages from Apertis can be found
+package repository. The open-source packages from Apertis can be found
 in the public
-[Apertis Debian repositories](https://repositories.apertis.org/apertis/).
+[Apertis package repositories](https://repositories.apertis.org/apertis/).
 
 The packages in these repositories can then be used to build images suitable
 for deployment onto a variety of targets, e.g. hardware boards (reference or
-product specific), virtual machines (e.g. for development), container images
-etc etc.
+product specific), virtual machines (e.g. for development), container images,
+etc.
+
+![Image generation from binary packages](/images/workflow_basic-image-generation.svg)
 
 The overall strategy for building these deployments is to separate it in
 various stages starting with early common stages (e.g. a common rootfs) and