docs: Project Rename

* Project rename
* adr directory removed
* Closes distro/docs#77

Signed-off-by: Gururaj Shetty <gururaj.shetty@huawei.com>

docs/adr/.adr-dir

-.

docs/adr/.adr-dir.license

-# SPDX-FileCopyrightText: Huawei Inc.
-#
-# SPDX-License-Identifier: Apache-2.0
\ No newline at end of file

docs/adr/0001-record-architecture-decisions.md

-<!--
-SPDX-FileCopyrightText: Huawei Inc.
-
-SPDX-License-Identifier: Apache-2.0
--->
-
-# 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).

docs/adr/0002-use-yocto-bitbake-for-building-ohos.md

-<!--
-SPDX-FileCopyrightText: Huawei Inc.
-
-SPDX-License-Identifier: Apache-2.0
--->
-
-# 2. Use Yocto / bitbake for building OHOS
-
-Date: 2020-12-01
-
-## Status
-
-Accepted
-
-## Context
-
-OHOS as a distributed operating system is designed to be hosted on 
-top of OS kernel. Currently Liteos-a (targeting ARM Cortex-A based devices) 
-and Liteos-m (targeting ARM Cortex-M based devices) kernels are supported.
-
-OHOS Liteos-A has BSP for only two ip cameras devices, whereas Liteos-M
-has BSP for only one wifi iot device. Qemu support is missing.
-
-## Decision
-
-To leverage existing BSPs OHOS will be made compatible with Yocto.
-We will start with Linux Poky distribution for ARM Cortex-A based devices
-and Zephyr for the Cortex-M based devices.
-
-## Consequences
-
-meta-ohos layer (when done properly) will enable nearly effortless porting 
-of OHOS to new kernels / distros.
-
-Decoupling of existing OHOS services from Liteos-A/M kernels has to be done.
-
-HQ modification to the OHOS stack between releases can require repeating
-decoupling works with each and every release if we're not aligned and in sync.

docs/adr/0003-ohos-environment-setup-for-various-kernels.md

-<!--
-SPDX-FileCopyrightText: Huawei Inc.
-
-SPDX-License-Identifier: Apache-2.0
--->
-
-# 3. OHOS environment setup for various kernels
-
-Date: 2020-12-18
-
-## Status
-
-Accepted
-
-## Context
-
-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.
-
-## Decision
-
-Add OHOS kernel flavours which
-will contain all necessary bitbake sample files (e.g. local.conf.sample,
-bblayers.conf.sample, etc.) that can be used together with 
-oe-init-build-env script:
-
-    TEMPLATECONF=sources/ohos/flavours/zephyr/conf . oe-init-build-env build-zephyr
-
-This will create a build-zephyr/conf directory based on the contents 
-of meta-ohos-zephyr/conf where all required layers and configs 
-can be defined. The same applies 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: 
-```plantuml
-!includeurl https://raw.githubusercontent.com/RicardoNiepel/C4-PlantUML/release/1-0/C4_Container.puml
-
-LAYOUT_AS_SKETCH()
-
-Person(dev, "Developer", "Anyone willing to build the OHOS based image")
-System_Boundary(ohos, "OHOS") {
-    Boundary(ohos_flavours, "flavours") {
-        Container(zephyr_config, "zephyr", "bb sample files", "Layer set and initial configuration for OHOS on Zephyr")
-        Container(linux_config, "linux", "bb sample files", "Layer set and initial configuration for OHOS on Poky")
-    }
-    Container(meta_ohos_foundation, "meta-ohos-foundation", "meta-layer", "OHOS foundation service (samgr, softbus)")
-    Container(ohos_docs, "docs", "Documentation", "OHOS build system documentation")
-}
-
-Container(meta_zephyr, "meta-zephyr", "meta-layer", "ZephyrOS meta-layer")
-System_Ext(yocto, "yocto-poky", "distro scaffolding: predefined meta-data, bitbake build system")
-
-Rel(dev, yocto, "1. selects OHOS Zephyr flavour", "environment shell script")
-Rel(yocto, zephyr_config, "2. gets default OHOS Zephyr configuration and sets up build environemt", "conf/ subdirectory")
-Rel(dev, yocto, "3. initiates the build", "bitbake")
-Rel(yocto, meta_ohos_foundation, "4. incorporates Zephyr-compatible OHOS layers")
-Rel(yocto, meta_zephyr, "4. incorporates upstream yocto layers")
-
-Lay_D(zephyr_config, linux_config)
-Lay_D(meta_ohos_foundation, ohos_docs)
-```
-
-## Consequences
-
-The benefit of that approach is that a single command is sufficient
-to setup the OHOS build environment for a selected kernel. All 
-required layers and configs are pre-defined.
-
-On the down side, this approach can lead to problems when the default
-_build_ directory is used for working with different kernels.
-When sourcing _oe-init-bild-env_ script, it will create _conf/_ 
-basing on the directory pointed to by TEMPLATECONF variable
-only when one is missing.
-
-Example:
-
-Working with Zephyr in default _build_ directory instead of e.g. _build-zephyr_:
-
-    TEMPLATECONF=sources/ohos/flavours/zephyr/conf . oe-init-build-env
-
-Then switching to Poky also in default _build_ directory:
-
-    TEMPLATECONF=sources/ohos/flavours/poky/conf . oe-init-build-env
-    # this command will not result in changing the environment setup
-    # as the _build/conf_ directory already exists

docs/adr/README.md

-<!--
-SPDX-FileCopyrightText: Huawei Inc.
-
-SPDX-License-Identifier: Apache-2.0
--->
-
-Architectural Decision Records
-==============================
-
-[All decisions for architecturally significant requirements](adr-list.md) are documented
-using [adr-tools](https://github.com/npryce/adr-tools).
-
-Decisions are to be discussed within MR of a given decision md file.
-

docs/adr/adr-list.md

-<!--
-SPDX-FileCopyrightText: Huawei Inc.
-
-SPDX-License-Identifier: Apache-2.0
--->
-
-# Architecture Decision Records
-
-* [1. Record architecture decisions](0001-record-architecture-decisions.md)
-* [2. Use Yocto / bitbake for building OHOS](0002-use-yocto-bitbake-for-building-ohos.md)
-* [3. OHOS environment setup for various kernels](0003-ohos-environment-setup-for-various-kernels.md)

docs/blueprints/doorlock.rst

@@ -138,13 +138,13 @@ The Software
 Get sources
 ===========
 #.
- Get |main_project_name| sources as described in the :ref:`documentation <AllScenariOSQuickBuild>`.
+ Get |main_project_name| sources as described in the :ref:`documentation <OniroQuickBuild>`.
 #.
  If you already have sources cloned, update them to the most recent revision
 
 .. code-block:: bash
 
- user@pc:~/ohos$ repo sync -d
+ user@pc:~/oniro$ repo sync -d
 
 Resources
 =========

docs/blueprints/smart-panel.rst

@@ -136,7 +136,7 @@ IoT devices
 Get sources
 ***********
 #. 
-   Get |main_project_name| sources as described in the :ref:`documentation <AllScenariOSQuickBuild>`.
+   Get |main_project_name| sources as described in the :ref:`documentation <OniroQuickBuild>`.
 
 #. 
    If you already have sources cloned, update them to the most recent revision

docs/blueprints/touchpanel.rst

@@ -28,14 +28,14 @@ The TouchPanel Blueprint provides support for building a PoC smart touch panel t
 Get sources
 ***********
 #. 
-   Get |main_project_name| sources as described in the :ref:`documentation <AllScenariOSQuickBuild>`.
+   Get |main_project_name| sources as described in the :ref:`documentation <OniroQuickBuild>`.
 
 #. 
    If you already have sources cloned, update them to the most recent revision
 
    .. code-block:: bash
 
-      user@pc:~/ohos$ repo sync -d
+      user@pc:~/oniro$ repo sync -d
 
 Resources
 =========

docs/blueprints/transparent-gateway.rst

@@ -63,7 +63,7 @@ For more details, the used `OpenThread configuration script <https://git.ostc-eu
 Get sources
 ***********
 
-#. Get |main_project_name| sources as described in the :ref:`documentation <AllScenariOSQuickBuild>`.
+#. Get |main_project_name| sources as described in the :ref:`documentation <OniroQuickBuild>`.
 #. If you already have sources cloned, update them to the most recent revision.
 
    .. code-block:: bash

docs/blueprints/vending-machine-dev.rst

@@ -245,13 +245,13 @@ order" message and show a "reset" button to refresh for the next order.
 Software Dependencies Versions
 ------------------------------
 
-ASOS supports the following libraries for message encoding/decoding/parsing and
+Oniro Project supports the following libraries for message encoding/decoding/parsing and
 the communication protocol:
 
 * `libwebsockets <https://libwebsockets.org/>`_ 4.0.1
 
 * `cjson <https://github.com/DaveGamble/cJSON/>`_ 1.7.13 (to be upgraded to
-  1.7.14 for OHOS convergence reasons)
+  1.7.14 for OpenHarmony convergence)
 
 * `json-c <https://github.com/json-c/json-c>`_ 0.13.1
 

docs/blueprints/vending-machine.rst

@@ -24,14 +24,14 @@ build an end-to-end solution using multiple operating systems cooperating inside
 Get sources
 ***********
 #. 
-   Get |main_project_name| sources as described in the :ref:`documentation <AllScenariOSQuickBuild>`.
+   Get |main_project_name| sources as described in the :ref:`documentation <OniroQuickBuild>`.
 
 #. 
    If you already have sources cloned, update them to the most recent revision
 
    .. code-block:: bash
 
-      user@pc:~/ohos$ repo sync -d
+      user@pc:~/oniro$ repo sync -d
 
 Architecture and Interfaces
 ***************************

docs/build-flavours/freertos-flavour.rst

@@ -23,7 +23,7 @@ Build steps example:
 
 .. code-block:: console
 
-    $ TEMPLATECONF=../oniro/flavours/freertos . ./oe-core/oe-init-build-env build-ohos-freertos
+    $ TEMPLATECONF=../oniro/flavours/freertos . ./oe-core/oe-init-build-env build-oniro-freertos
     $ bitbake freertos-demo
 
 You can test the image built for the qemuarmv5 target by issuing:

docs/build-flavours/linux-flavour.rst

@@ -13,10 +13,10 @@ Linux Kernel Build Flavour
 
 Supported images:
 
-* allscenarios-image-base
-* allscenarios-image-base-tests
-* allscenarios-image-extra
-* allscenarios-image-extra-tests
+* oniro-image-base
+* oniro-image-base-tests
+* oniro-image-extra
+* oniro-image-extra-tests
 
 Supported machines (default in **bold**):
 
@@ -32,14 +32,14 @@ Build steps example:
 
 .. code-block:: console
 
-    $ TEMPLATECONF=../oniro/flavours/linux . ./oe-core/oe-init-build-env build-ohos-linux
-    $ bitbake allscenarios-image-base
+    $ TEMPLATECONF=../oniro/flavours/linux . ./oe-core/oe-init-build-env build-oniro-linux
+    $ bitbake oniro-image-base
 
 You can test the image built for the qemux86-64 target by issuing:
 
 .. code-block:: console
 
-    $ runqemu qemux86-64 allscenarios-image-base wic
+    $ runqemu qemux86-64 oniro-image-base wic
 
 After successful bootup, you will be dropped into a login shell:
 

docs/build-flavours/zephyr-flavour.rst

@@ -31,7 +31,7 @@ Build steps example:
 
 .. code-block:: console
 
-    $ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-ohos-zephyr
+    $ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-zephyr
     $ bitbake zephyr-philosophers
 
 You can test the image built for the qemu-x86 target by issuing:

docs/ci/hidden-jobs/workspace.rst

@@ -57,7 +57,7 @@ CI_ONIRO_MANIFEST_URL
 The URL consumed by git-repo. You only want to change this if you forked the
 entire infrastructure and want to use it in private.
 
-The default value is ``https://git.ostc-eu.org/OSTC/OHOS/manifest``.
+The default value is ``https://git.ostc-eu.org/distro/manifest``.
 
 If you change the default value, please set ``CI_ONIRO_MANIFEST_MIRROR``
 as well.

docs/ci/machines-and-flavours.rst

@@ -13,7 +13,7 @@ combination of ``FLAVOUR`` and ``MACHINE``.
 
 .. warning::
 
-    Do not include YAML files from the meta-ohos repository directly. The
+    Do not include YAML files from the oniro repository directly. The
     primary entry point for build and test pipelines is defined by the manifest
     repository.
 

docs/hardware-support/boards/96b-Avenger.rst

@@ -31,8 +31,8 @@ For more details on Avenger96 board, see `Avenger96 product page <https://www.96
 Working with the board
 **********************
 
-Building OHOS image
-===================
+Building an Oniro image
+=======================
 
 To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
 
@@ -50,14 +50,14 @@ Linux image
    $ TEMPLATECONF=../oniro/flavours/linux . ./oe-core/oe-init-build-env build-oniro-linux
 
 2. You will find yourself in the newly created build directory. Call *bitbake*
-   to build the image. For example, if you are using *allscenarios-image-base*
+   to build the image. For example, if you are using *oniro-image-base*
    run the following command:
 
 .. code-block:: console
 
-   $ MACHINE=stm32mp1-av96 bitbake allscenarios-image-base
+   $ MACHINE=stm32mp1-av96 bitbake oniro-image-base
 
-To generate images for eMMC on SD card, refer to the :ref:`Flashing OHOS image <Flashing_ohos>`.
+To generate images for eMMC on SD card, refer to the :ref:`Flashing an Oniro image <Flashing_oniro>`.
 
 Zephyr image
 ------------
@@ -79,10 +79,10 @@ Zephyr image
 3. The output file will be located in the build directory
    *./tmp-newlib/deploy/images/96b-avenger96/*.
 
-.. _Flashing_ohos:
+.. _Flashing_oniro:
 
-Flashing OHOS image
-*******************
+Flashing an Oniro image
+***********************
 
 For Linux, `bmaptool <https://github.com/intel/bmap-tools>` is recommended to
 create an SD card image. The images we provide also create wic files (disk
@@ -112,13 +112,13 @@ For more information on Avenger96 boot options, see `Getting Started with the Av
 1. After the image is built, you are ready to burn the generated image onto the
    SD card. We recommend using `bmaptool <https://github.com/intel/bmap-tools>`
    and the instructions below will use it. For example, if you are building
-   allscenarios-image-base run the following command replacing (or defining)
+   oniro-image-base run the following command replacing (or defining)
    ``$DEVNODE`` accordingly:
 
 .. code-block:: console
 
    $ cd tmp/deploy/images/stm32mp1-av96
-   $ bmaptool copy allscenarios-image-base-stm32mp1-av96.wic.bz2 $DEVNODE
+   $ bmaptool copy oniro-image-base-stm32mp1-av96.wic.bz2 $DEVNODE
 
 2. Put the card to the board and turn it on.
 
@@ -127,7 +127,7 @@ STM32 Cube Programmer
 
 After you build the image, follow the instructions in `Avenger96 Image Programming <https://wiki.dh-electronics.com/index.php/Avenger96_Image_Programming>`_,
 pointing the program to the
-*./tmp/deploy/images/stm32mp1-av96/flashlayout_allscenarios-image-base/trusted/FlashLayout_emmc_stm32mp157a-av96-trusted.tsv*
+*./tmp/deploy/images/stm32mp1-av96/flashlayout_oniro-image-base/trusted/FlashLayout_emmc_stm32mp157a-av96-trusted.tsv*
 flash layout file.
 
 .. _zephyr-image-1:

docs/hardware-support/boards/96b-nitrogen.rst

@@ -46,7 +46,7 @@ Building an application
 
 .. code-block:: console
 
-   $ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-ohos-zephyr
+   $ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-zephyr
 
 * You will find yourself in the newly created build directory. Call bitbake to build the image. The supported image name is zephyr-philosophers.