diff options
Diffstat (limited to '')
| -rw-r--r-- | user/hardware/tiers.rst | 33 |
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. |