path: root/docs/contributing
diff options
authorSummer Qin <summer.qin@arm.com>2021-04-06 17:22:15 +0800
committerSummer Qin <summer.qin@arm.com>2021-04-21 10:34:53 +0800
commitabf6698dd6b916de5aea971783aa80776bf296dd (patch)
tree7e1727767491c52d7bce438d2bf88c89fb05da78 /docs/contributing
parentcdaec9c383182052b8535b74e92a4799b98236cd (diff)
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
Diffstat (limited to 'docs/contributing')
-rw-r--r--docs/contributing/contributing_process.rst (renamed from docs/contributing/contributing.rst)6
9 files changed, 21 insertions, 133 deletions
diff --git a/docs/contributing/code_review_guide.rst b/docs/contributing/code_review_guide.rst
index 8bbf33aa2b..e9ed9699f4 100644
--- a/docs/contributing/code_review_guide.rst
+++ b/docs/contributing/code_review_guide.rst
@@ -13,9 +13,9 @@ List of the guidelines
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 @@ SPRTL secure-fw/partitions/lib/sprt/*
-*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 099d3b3fc1..f208fc0944 100644
--- a/docs/contributing/coding_guide.rst
+++ b/docs/contributing/coding_guide.rst
@@ -18,7 +18,7 @@ remain within clear scope.
The guidance below is provided as a help. It isn't meant to be a definitive
-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
@@ -76,4 +76,4 @@ List of rules
-*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
index 9c80cab957..b017c638a9 100644
--- a/docs/contributing/contributing.rst
+++ b/docs/contributing/contributing_process.rst
@@ -1,5 +1,5 @@
+Contributing Process
Contributions to the TF-M project need to follow the process below.
@@ -77,4 +77,4 @@ Contributions to the TF-M project need to follow the process below.
-*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 e217dde571..41f4e05c98 100644
--- a/docs/contributing/doc_guidelines.rst
+++ b/docs/contributing/doc_guidelines.rst
@@ -187,7 +187,7 @@ will not be added to the index (So it cannot be referenced if needed)
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
External Links
@@ -260,7 +260,7 @@ Glossary term
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:`
@@ -297,4 +297,4 @@ References
-*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 7b921f25dc..e5f9c66be6 100644
--- a/docs/contributing/index.rst
+++ b/docs/contributing/index.rst
@@ -1,15 +1,13 @@
+Contribution Guidelines
.. toctree::
:maxdepth: 1
- :caption: Contents
- 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 aeced913bd..ced48d167a 100644
--- a/docs/contributing/maintainers.rst
+++ b/docs/contributing/maintainers.rst
@@ -111,8 +111,8 @@ Michel JAOUEN
: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 5d7a3de987..0000000000
--- 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
-| 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 8b6d1965b1..0000000000
--- 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:
-- <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 0be4d04e75..fcc2be9d74 100644
--- a/docs/contributing/tfm_design_proposal_process.rst
+++ b/docs/contributing/tfm_design_proposal_process.rst
@@ -49,7 +49,7 @@ Example document fragment::
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 @@ Process steps
- 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 @@ Process steps
.. uml::
- !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 @@ Process steps
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*