apt-publisher: Expand challenges and goals of the aptly publisher

Add a couple more issues with the reprepro publisher and describe how
the Aptly publisher addresses them.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

content/concepts/infrastructure/apt-publisher.md

@@ -19,6 +19,13 @@ Apertis, where a single OBS project contains a lot of packages.
 Therefore, our OBS instance uses a custom publisher based on `reprepro`, but
 it is still subject to some limitations that are now more noticeable as the
 scale of Apertis has grown considerably:
+
+* It purely acts on the events created by OBS, which means that if they do not
+  get successfully processed immediately the repository will go out-of-sync
+* The repositories are hosted on the same machine as OBS, and there is no way for
+  external tools to interact with them; for instance there is no way to request
+  the creation of snapshots with a different strategy than the current one of
+  creating a snapshot for every single change
 * When branching a release `reprepro` has to be invoked manually to initialize
   the exported repositories
 * When branching a release the OBS publisher has to be manually disabled or it
@@ -34,9 +41,12 @@ In order to address these shortcomings, we need to develop a new APT publisher
 * Natively supporting snapshots
 * Automatic branching of an Apertis release, not requiring manual intervention
   on the APT publisher
-* Synchronize OBS and APT repositories; as an example, removing a package from
-  OBS should trigger the removal of the package from the APT repositories as
-  well
+* Using a synchronization strategy to ensure that OBS and APT repositories
+  automatically tend to consistent state:
+  * removing a package from OBS should trigger the removal of the package from
+    the APT repositories as well
+  * once a publishing failure is resolved (network issues, etc.) the publisher
+    should recover automatically
 
 # Alternatives to `reprepro`