summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJoel Sherrill <joel@rtems.org>2019-12-09 14:59:49 -0600
committerJoel Sherrill <joel@rtems.org>2019-12-12 10:59:38 -0600
commit01be51383f39afb3803a05f4bbcce5d91737b06e (patch)
tree692ab68ef41e7e7c4e0ed56d6ef38f49c5a5c842
parentf7d56f579869ff0bd3acd95c8e245743605f4633 (diff)
downloadrtems-docs-01be51383f39afb3803a05f4bbcce5d91737b06e.tar.bz2
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.
-rw-r--r--user/hardware/tiers.rst33
1 files 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.