Docs: Restructure the documents
Restructure the file category to let it more friendly to users.
Signed-off-by: Summer Qin <summer.qin@arm.com>
Change-Id: I7ced0e2d700ce03423e472e0098608f3445ba169
diff --git a/docs/contributing/code_review_guide.rst b/docs/contributing/code_review_guide.rst
index 8bbf33a..e9ed969 100644
--- a/docs/contributing/code_review_guide.rst
+++ b/docs/contributing/code_review_guide.rst
@@ -13,9 +13,9 @@
**********************
The prerequisites before going to the review stage:
-- Read the :doc:`Contributing Guidelines </docs/contributing/contributing>`
+- Read the :doc:`Contributing Process </docs/contributing/contributing_process>`
to know basic concepts.
-- Read the :doc:`Source Structure </docs/design_documents/source_structure>`
+- Read the :doc:`Source Structure </docs/technical_references/source_structure>`
for structure related reference.
The review guidelines consist of these items:
@@ -234,4 +234,4 @@
--------------
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/docs/contributing/coding_guide.rst b/docs/contributing/coding_guide.rst
index 099d3b3..f208fc0 100644
--- a/docs/contributing/coding_guide.rst
+++ b/docs/contributing/coding_guide.rst
@@ -18,7 +18,7 @@
The guidance below is provided as a help. It isn't meant to be a definitive
list.
-As implied in the :doc:`contributing guide </docs/contributing/contributing>`
+As implied in the :doc:`contributing guide </docs/contributing/contributing_process>`
maintainers have the right to decide on what's acceptable in case of any
divergence.
@@ -76,4 +76,4 @@
--------------
-*Copyright (c) 2018-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2018-2021, Arm Limited. All rights reserved.*
diff --git a/docs/contributing/contributing.rst b/docs/contributing/contributing_process.rst
similarity index 96%
rename from docs/contributing/contributing.rst
rename to docs/contributing/contributing_process.rst
index 9c80cab..b017c63 100644
--- a/docs/contributing/contributing.rst
+++ b/docs/contributing/contributing_process.rst
@@ -1,5 +1,5 @@
-Contributing
-============
+Contributing Process
+====================
Contributions to the TF-M project need to follow the process below.
@@ -77,4 +77,4 @@
--------------
-*Copyright (c) 2017-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2017-2021, Arm Limited. All rights reserved.*
diff --git a/docs/contributing/doc_guidelines.rst b/docs/contributing/doc_guidelines.rst
index e217dde..41f4e05 100644
--- a/docs/contributing/doc_guidelines.rst
+++ b/docs/contributing/doc_guidelines.rst
@@ -187,7 +187,7 @@
Other types of tables such as list-tables and csv-tables are also permitted, as
seen on :doc:`/docs/getting_started/tfm_sw_requirement` and
-:doc:`/docs/reference/releases/1.0`
+:doc:`/docs/releases/1.0`
External Links
@@ -260,7 +260,7 @@
=============
For technical terms and abbreviations, the recommended guidance is to add an
-entry to the :doc:`/docs/reference/glossary` and refer to it, using the `term:`
+entry to the :doc:`/docs/glossary` and refer to it, using the `term:`
directive
@@ -297,4 +297,4 @@
--------------
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/docs/contributing/index.rst b/docs/contributing/index.rst
index 7b921f2..e5f9c66 100644
--- a/docs/contributing/index.rst
+++ b/docs/contributing/index.rst
@@ -1,15 +1,13 @@
-Contributing
-============
+Contribution Guidelines
+=======================
.. toctree::
:maxdepth: 1
- :caption: Contents
:glob:
*
- Security Center <https://developer.trustedfirmware.org/w/collaboration/security_center>
--------------
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/docs/contributing/maintainers.rst b/docs/contributing/maintainers.rst
index aeced91..ced48d1 100644
--- a/docs/contributing/maintainers.rst
+++ b/docs/contributing/maintainers.rst
@@ -111,8 +111,8 @@
:github: `jamike <https://github.com/jamike>`__
-Infineon/Cypress Platform:
-~~~~~~~~~~~~~~~~~
+Infineon/Cypress Platforms
+~~~~~~~~~~~~~~~~~~~~~~~~~~
Chris Brand
:email: `Chris Brand@cypress.com <chris.brand@cypress.com>`__
diff --git a/docs/contributing/platform_deprecation.rst b/docs/contributing/platform_deprecation.rst
deleted file mode 100644
index 5d7a3de..0000000
--- a/docs/contributing/platform_deprecation.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-################################
-Platform deprecation and removal
-################################
-
-********************************************
-Process for Platform deprecation and removal
-********************************************
-
-A platform may need to be removed from upstream code due to lack of community
-interest or it may have reached end of life. The below section calls out the
-process for removing platform support from TF-M.
-
- 1. An email to the TF-M mailing list proposing the removal of the platform.
-
- 2. The merit of the proposal will be considered by the maintainers for a
- period of 4 weeks and community can express their opinion on the same
- during this time window. The platform owner can veto the proposal and
- incase of multiple platform owners with differing opinion or community
- having interest in the platform, then the project maintainer can work
- with the platform owner and use their discretion to decide on the
- proposal.
-
- 3. Once a decision is made to remove the platform, the platform is
- considered to be in `deprecated` state as per platform support lifecyle
- defined here: "https://developer.trustedfirmware.org/w/collaboration/project-maintenance-process/".
- The platform will be marked as deprecated and the TF-M version after
- which it will be removed will also be mentioned. Suitable build time
- or runtime messages needs to be incorporated to the platform to warn
- about the `deprecation`.
-
- 4. The project should strive to keep the `deprecated` platforms
- building/running till the removal. This relies on platform owners being
- still actively involved with the project and maintaining the platform.
-
- 5. Although this will be the usual process for platform deprecation and
- eventual removal, the process still leaves room for the platform
- deprecation to be cancelled after it has been marked as `deprecated`
- due to evolving project and market requirements. This is left to
- consensus between project maintainers and platform owner/s.
-
- 6. Once a platform has been removed, it can be added back in future and
- this would follow the same guidelines as for a new platform contribution.
-
-****************************
-List of Deprecated Platforms
-****************************
-
-The below list calls out platforms marked for deprecation according to the
-above process and the platform will be removed soon after the mentioned
-release.
-
-+--------------------------------------+-----------+---------------------------+
-| Deprecated Platform | Removed | Comments |
-| | after | |
-| | release | |
-+======================================+===========+===========================+
-| mps2/an539 | v1.2.0 | N.A |
-+--------------------------------------+-----------+---------------------------+
-| mps2/sse-200_aws | v1.3.0 | N.A |
-+--------------------------------------+-----------+---------------------------+
-| musca_a | v1.3.0 | N.A |
-+--------------------------------------+-----------+---------------------------+
-| nordic_nrf/nrf5340pdk_nrf5340_cpuapp | v1.3.0 | N.A |
-+--------------------------------------+-----------+---------------------------+
-
---------------
-
-*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/docs/contributing/release_process.rst b/docs/contributing/release_process.rst
deleted file mode 100644
index 8b6d196..0000000
--- a/docs/contributing/release_process.rst
+++ /dev/null
@@ -1,42 +0,0 @@
-Release Cadence and Process
-===========================
-
-Project Release Cadence
------------------------
-
-The project currently aims to do a release once every 4 months which will be
-tagged on the master branch. There will be a code freeze (stop merging
-non-essential changes) up to 3 weeks prior to the target release date. The
-release candidates will start appearing after this and only bug fixes or
-updates required for the release will be merged. The maintainers are free
-to use their judgement on what changes are essential for the release.
-
-The release testing will be performed on release candidates and depending on
-issues found, additional release candidates may be created to fix the issues.
-
-::
-
- |<------------4 months----------->|
- |<--upto 3 weeks-->| |<--upto 3 weeks-->|
- +----------------------------------------------------- ----------> time
- | | | |
- code freeze ver w.x code freeze ver y.z
-
-Although this document specifies the release cadence, this does not preclude
-an adhoc release for specific project requirements.
-
-Release Version Scheme
-----------------------
-
-Trusted Firmware-M uses a semantic versioning scheme. A version number is
-compiled as a dot separated set of numbers:
-
-**TF-Mv<MAJOR>.<MINOR>.<HOTFIX>**
-
-- <MAJOR>: Major release version for significant feature and API changes.
-- <MINOR>: Minor release version for incremental features and API changes.
-- <HOTFIX>: Used only for backporting **critical bug fix/security patches**.
-
---------------
-
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
diff --git a/docs/contributing/tfm_design_proposal_process.rst b/docs/contributing/tfm_design_proposal_process.rst
index 0be4d04..fcc2be9 100644
--- a/docs/contributing/tfm_design_proposal_process.rst
+++ b/docs/contributing/tfm_design_proposal_process.rst
@@ -49,7 +49,7 @@
Design documents are kept in three different sections of the documentation
reflecting the status of the document. The status of the document determines
the section it is in. Open (*Draft* and *Detailed* status) and accepted design
-documents shall be put to the ``docs/design_documents`` directory.
+documents shall be put to the ``docs/technical_references`` directory.
.. important::
- 'Author' and 'Organization' can be *OPTIONAL* but at least one of them is
@@ -78,7 +78,7 @@
- Write the design proposal in the format that is described in this document
with the *Status* set to *Draft* if *Status* field is provided. Put it to the
- ``docs/design_documents`` directory and create a pull request.
+ ``docs/technical_references`` directory and create a pull request.
- Start an e-mail thread on the
`TF-M mailing list <mailto:tf-m@lists.trustedfirmware.org>`_ for discussing
the proposal.
@@ -98,8 +98,8 @@
.. uml::
@startuml
- !define DRAFT_DIR **docs/design_documents/**
- !define REJECTED_DIR **docs/design_documents/rejected/**
+ !define DRAFT_DIR **docs/technical_references/**
+ !define REJECTED_DIR **docs/technical_references/rejected/**
!define GERRIT_URL https://review.trustedfirmware.org
!define GERRIT_LINK [[GERRIT_URL trustedfirmware.org]]
!define MAINTAINER_RST_URL https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/maintainers.rst
@@ -153,4 +153,4 @@
--------------
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*