Fix typos and minor issues on long-term-reproducibility.md

This commit fixes typos and small issues on the long term
reproducibility document.

Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>

content/architecture/long-term-reproducibility.md

@@ -48,7 +48,7 @@ has multiple active release channels to both provide a stable foundation for
 product teams and also give them full visibility on the latest developments.
 
 Each release channel has its own artefacts, the main one being the
-[deployable images](https://apertis.org/images/) targeting the [reference
+[deployable images](https://images.apertis.org/) targeting the [reference
 hardware platforms](https://www.apertis.org/reference_hardware/), which get
 built by mixing:
 
@@ -66,7 +66,7 @@ channels is that each channel should have its own set of inputs, so that
 changes in a channel do not impact other channels.
 
 Even within channels sometimes it is desirable to reproduce a past build
-as closely as possible, for instance to deliver an hotfix to an existing
+as closely as possible, for instance to deliver a hotfix to an existing
 product while minimizing the chance of introducing regressions due to
 unrelated changes. The Apertis goal of reliable, reproducible builds does
 not only help developers in their day-to-day activities, but also gives
@@ -218,7 +218,7 @@ original as possible, ignoring any update regardless of their importance.
 
 To accomplish that goal the package archives are snapshotted regularly,
 storing their full history. The image build pipeline accepts an optional
-parameters to use a specific snapshot rather than the latest contents.
+parameter to use a specific snapshot rather than the latest contents.
 This results in the execution installing exactly the same packages and
 versions as the original run, regardless of any changes that landed in the
 archive in the meantime.
@@ -314,7 +314,7 @@ latest package versions for each channel.
 
 Since the purposes taken in account in this document do not involve large scale
 package rebuilds, it is recommended to use the SDK images and the devroots in
-combination with the snapshotted APT archives to rebuild packages in a
+combination with the snapshotted APT archives to rebuild packages in an
 environment closely matching a past build.
 
 # Recommendations for product teams
@@ -586,7 +586,7 @@ relevant hashes that were used to create an image. The outcome of the planned
 work will be the publication of text files containing all relevant hashes for
 future use.
 
-## Using the Golden components two years after release 1.0.0: Creating the new release
+## Using the golden components two years after release 1.0.0: Creating the new release
 
 We recommend product teams to make constant releases, for example in a quarterly
 basis, to cover security updates and to minimize the technical debt to Apertis