Introducing adr-tools

To manage architecture decision records the adr-tools will be used.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

README.md

@@ -6,3 +6,9 @@ meta-ohos architecture is documented using [c4 model](https://c4model.com/).
 ## meta-ohos context diagram
 ![meta-ohos system context diagram](./diagrams/meta-ohos_system_context_diagram.svg)
 
+## Architecture Decision Records
+All decisions for architecturally significant requirements are documented
+using [adr-tools](https://github.com/npryce/adr-tools) and stored in [adr](./adr) subdirectory.
+
+Decisions are to be discussed within MR of a given decision md file.
+

adr/.adr-dir

+.

adr/0001-ohos-environment-setup.md

-OHOS environment setup for different kernels
-============================================
-
-Given that OHOS will run on multiple different kernels we need 
-a straight-forward way of setting up build environment.
-There are many possible solutions, so we need to pick a sensible one
-that'll suit our needs.
-
-## Configuration / adaptation layers for kernels withing meta-openharmony
-
-One option is to make configuration / adaptaion layer per kernel which
-will contain all necessary bitbake configs (e.g. local.conf.sample,
-bblayers.conf.sample, etc.) that can be used together with oe-init-build-env
-script:
-
-    TEMPLATECONF=meta-openharmony/meta-ohos-zephyr/conf . oe-init-build-env
-
-This will create a build/conf directory based on the contents of meta-ohos-zephyr/conf
-where all required layers and configs can be defined. The same applise for other
-kernels, like FreeRTOS, Liteos or any other Linux-based distro.
-
-Below is a sequence diagram of how this could look like for Zephyr: 
-![ohos-zephyr-build-sequence-diagram](../diagrams/0001-meta-openharmony-zephyr-build-sequence-diagram.svg)
-

adr/0001-record-architecture-decisions.md

+# 1. Record architecture decisions
+
+Date: 2020-11-30
+
+## Status
+
+Accepted
+
+## Context
+
+We need to record the architectural decisions made on this project.
+
+## Decision
+
+We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+
+## Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools).

adr/README.md

 Architectural Decision Records
 ==============================
 
-Here we keep all Architectural Decision Records.
-Each decision shall be in a separate file with name following convention:
+[All decisions for architecturally significant requirements](adr-list.md) are documented
+using [adr-tools](https://github.com/npryce/adr-tools).
 
-NNNN-title-with-dashes.md
+Decisions are to be discussed within MR of a given decision md file.
 
-where the NNNN is a decision number.

adr/adr-list.md

+# Architecture Decision Records
+
+* [1. Record architecture decisions](0001-record-architecture-decisions.md)