Small fix, rewrite the Package builds section

This MR:

• removes the use of snapshotted
• rewrites the Package builds section adding more details about package builds using the SDK, devroots and snapshots of APT archives. It mentions the differences between building on OBS and on the SDK and differences between native and emulated builds.

content/policies/contribution_process.md

@@ -515,3 +515,122 @@ Apertis infrastructure, please send an email to
 - Your full name
 - The email address you prefer to be contacted through
 - The nickname/account name you wish to be known by on the Apertis GitLab
+
+# Contribution Template
+
+This section contains a contribution template that illustrates the ideal first
+email a developer would send for adding a design document to Apertis. This
+template for the first email contains the description of the design document
+instead of the design document itself. The idea is to promote involving the
+Apertis team as early as possible, and ideally before completing the work.
+
+The rationale for this approach is that it is very difficult for an external
+contributor to understand the impact a contribution can bring to Apertis, and
+by asking early, the work can be done in ways that are compatible with Apertis
+and welcome by the Apertis team.
+
+```
+From: Your name <your email>
+To: devel@lists.apertis.org
+Subject: Robot Framework design document
+
+Hi,
+
+I want to contribute to Apertis, and I am sending this email to ask if our
+proposal can be added to Apertis. I am sending the email based on the
+contribution template I found on the Apertis website, and we are looking
+forward for receiving feedback from the Apertis team.
+
+Thank you,
+
+Your name
+
+-- // --
+
+1. Me and my team
+I am a developer, I am specialized in embedded devices, and I work in a product
+team that creates IoT devices with all sorts of environmental sensors and
+actuators.
+
+
+2. What is the goal of my proposal
+My proposal is for a design document that describes tools and workflows for
+process automation using the Robot Framework. The Robot Framework is a generic
+open source automation framework that can be used for automation of tests and
+processes.
+
+- From our perspective this adds value to the Apertis Universe. Do you agree?
+
+
+2. State-of-the-art
+We prefer the Robot Framework because it is mature, it is simple to use, and
+because it has an active development community.
+
+While there are other automation frameworks available, they tend to be purpose
+specific. Examples of purpose specific automation frameworks that we considered
+include Selenium and JUnit.
+
+3. How does our contribution works?
+The Robot framework has a layered architecture. The top layer is the simple,
+powerful, and extensible keyword-driven descriptive language for testing and
+automation. This language resembles a natural language, is quick to develop, is
+easy to reuse, and is easy to extend. On the bottom layer of the architecture is
+the item to be tested, or the process to be automated.
+
+The middle layer is what makes the Robot Framework extensible: libraries. A
+library, in Robot Framework terminology, extends the Robot Framework language
+with new keywords, and provides the implementation for these new keywords. Each
+Robot Framework library acts as glue between the high level language and low
+level details of the item being tested, or of the environment in which the item
+to be tested is present.
+
+
+4. Potential impact on Apertis?
+We are aware there the architecture of the Robot Framework is different from the
+Archutecture of LAVA. In some cases the Robot Framework accepts human
+intervention with tests while LAVA expects everything to be automated. While we do
+not fully understand to which extent this will impact Apertis, we expect that for our
+design proposal will need to adapt to Apertis and LAVA constraints. Can you help us
+here?
+
+5. Benefits for Apertis?
+The Robot Framework project is active for many years and is used for a variety
+of use cases. We expect that adding the Robot Framework to the Apertis Universe
+will bring Robot Framework users to Apertis.
+
+
+6. What is the license of the main components?
+The Robot Framework itself is licensed under the Apache License 2.0, however
+Robot Framework libraries can use different licenses.
+
+
+7. The plan to integrate the design into Apertis
+Our understanding is that Apertis currently uses LAVA for testing, and that
+images being tested are as close to production images as possible (almost no
+testing instrumentation included). We propose to develop and/or modify a few
+Robot Framework libraries, and to create a run-time compatibility layer for LAVA.
+We expect that the combination of custom libraries with the run-time compatibility
+layer for LAVA will enable us to keep testing environments as close as possible
+to production environments, and to adapt the execution of Robot Framework tests
+to suit the Apertis and LAVA constraints.
+
+
+8. Estimated work to implement the design
+Our ballpark estimation to add or modify Robot Framework libraries and to create
+the run-time compatibility layer for LAVA is of approximatedly 1500 hours of
+work. But we need your help to fully understand the impact on the Apertis side.
+
+
+9. High level implementation plan
+While we understand our use case and requirements, we would like to receive
+feedback from other potential users as soon as possible. Our idea is to deploy
+the Robot Framework in stages to allow early involvement of other users:
+
+- Add Robot Framework to the Apertis SDK to enable developers to use the Robot
+Framework locally
+
+- Robot Framework Integration development: Adapt libraries and create the run-time
+compatibility layer for LAVA
+
+- Deployment on the Apertis infrastructure
+```