[rtems-docs commit] user/hardware/tiers.rst: Merge info from Wiki.

Joel Sherrill joel at rtems.org
Thu Dec 12 17:00:09 UTC 2019


Module:    rtems-docs
Branch:    master
Commit:    01be51383f39afb3803a05f4bbcce5d91737b06e
Changeset: http://git.rtems.org/rtems-docs/commit/?id=01be51383f39afb3803a05f4bbcce5d91737b06e

Author:    Joel Sherrill <joel at rtems.org>
Date:      Mon Dec  9 14:59:49 2019 -0600

user/hardware/tiers.rst: Merge info from Wiki.

Tiers had a write up on the Wiki which was similar but different.
Merged content from the Wiki which allows the Wiki page to be
deleted.

closes #3831.

---

 user/hardware/tiers.rst | 33 ++++++++++++++++++++++++++++-----
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/user/hardware/tiers.rst b/user/hardware/tiers.rst
index aeea26c..9465eb6 100644
--- a/user/hardware/tiers.rst
+++ b/user/hardware/tiers.rst
@@ -14,9 +14,32 @@ RTEMS has a tiered structure for architecture and BSPs. It provides:
 
 #. A quaility measure for changes entering the RTEMS source code.
 
+The RTEMS project supports RTEMS Architecture Tiers. Each architecture
+resided in one of the numbered tiers. The tiers are number 1 to 4 where
+Tier 1 is the highest tier and Tier 4 is the lowest. Architectures move
+between tiers based on the level of support and the level of testing that
+is performed. An architecture requires continual testing and reporting
+of test results to maintain a tier level. The RTEMS Project's continuous
+integration testing program` continually monitors and reports the test
+results.
+
+The RTEMS Architecture Tier system provides a defined way to determine
+the state of an architecture in RTEMS. Architectures age and support
+for them drops off and the RTEMS Project needs a way to determine
+if an architecture should stay and be supported or depreciated and
+removed. The tier system also provides users with a clear understanding of
+the state of an architecture in RTEMS, often useful when deciding on
+a processor for a new project. It can also let a user know the RTEMS
+Project needs support to maintain a specific architecture. Access to
+hardware to perform testing is a large and complex undertaking and the
+RTEMS Project is always looking for user support and help. If you can
+help please contact someone and let us know.
+
 The tier structure in RTEMS is support by the Buildbot continuous integration
 server. Changes to RTEMS are automatically built and tested and the results
-indicate if a BSP currently meets it's tier status.
+indicate if a BSP currently meets its tier status. As the RTEMS Project 
+does not own hardware for every BSP, it is critical that users provide
+test results on hardware of interest.
 
 The rules for Tiers are:
 
@@ -43,11 +66,11 @@ The rules for Tiers are:
 
 #. The tier level for a BSP is set by the RTEMS Project team. Movement of BSP
    between tier level requires agreement. The Buildbot results indicate the
-   current tier level.
+   minimum current tier level.
 
-#. Changes to RTEMS may result in a BSP not meeting it's tier are acceptable if
+#. Changes to RTEMS may result in a BSP not meeting its tier are acceptable if
    the change is accompanied by an announcement and a plan on how this is to be
-   resolved.
+   resolved. Temporary drops in tier are expected and should be brief.
 
 #. Test results are set on a per BSP basis by the RTEMS Project team. Changes
    to the test result values requires agreement. The test results are defined
@@ -58,4 +81,4 @@ The rules for Tiers are:
      #. Expected Failures
 
    Expected failures must be explicitly listed. A BSP is required to have a
-   valid test result entry to reach tier 1.
+   valid test result entry on target hardware to reach tier 1.



More information about the vc mailing list