|
| 1 | +This document is a declaration of software quality for the `diagnostic_msgs` package, based on the guidelines in [REP-2004](https://www.ros.org/reps/rep-2004.html). |
| 2 | + |
| 3 | +# `diagnostic_msgs` Quality Declaration |
| 4 | + |
| 5 | +The package `diagnostic_msgs` claims to be in the **Quality Level 4** category. |
| 6 | + |
| 7 | +Below are the rationales, notes, and caveats for this claim, organized by each requirement listed in the [Package Requirements for Quality Level 4 in REP-2004](https://www.ros.org/reps/rep-2004.html). |
| 8 | + |
| 9 | +## Version Policy [1] |
| 10 | + |
| 11 | +### Version Scheme [1.i] |
| 12 | + |
| 13 | +`diagnostic_msgs` uses `semver` according to the recommendation for ROS Core packages in the [ROS 2 Developer Guide](https://index.ros.org/doc/ros2/Contributing/Developer-Guide/#versioning). |
| 14 | + |
| 15 | +### Version Stability [1.ii] |
| 16 | + |
| 17 | +`diagnostic_msgs` is not yet at a stable version, i.e. `>= 1.0.0`. |
| 18 | + |
| 19 | +### Public API Declaration [1.iii] |
| 20 | + |
| 21 | +All message and service definition files located in `msg` and `srv` directories are considered part of the public API. |
| 22 | + |
| 23 | +### API Stability Within a Released ROS Distribution [1.iv]/[1.vi] |
| 24 | + |
| 25 | +`diagnostic_msgs` will not break public API within a released ROS distribution, i.e. no major releases once the ROS distribution is released. |
| 26 | + |
| 27 | +### ABI Stability Within a Released ROS Distribution [1.v]/[1.vi] |
| 28 | + |
| 29 | +`diagnostic_msgs` does not contain any C or C++ code and therefore will not affect ABI stability. |
| 30 | + |
| 31 | +## Change Control Process [2] |
| 32 | + |
| 33 | +`diagnostic_msgs` follows the recommended guidelines for ROS Core packages in the [ROS 2 Developer Guide](https://index.ros.org/doc/ros2/Contributing/Developer-Guide/#package-requirements). |
| 34 | + |
| 35 | +### Change Requests [2.i] |
| 36 | + |
| 37 | +This package requires that all changes occur through a pull request. |
| 38 | + |
| 39 | +### Contributor Origin [2.ii] |
| 40 | + |
| 41 | +This package uses DCO as its confirmation of contributor origin policy. More information can be found in [CONTRIBUTING](../CONTRIBUTING.md). |
| 42 | + |
| 43 | +### Peer Review Policy [2.iii] |
| 44 | + |
| 45 | +Following the recommended guidelines for ROS Core packages, all pull requests must have at least 1 peer review. |
| 46 | + |
| 47 | +### Continuous Integration [2.iv] |
| 48 | + |
| 49 | +All pull requests must pass CI on all [tier 1 platforms](https://www.ros.org/reps/rep-2000.html#support-tiers) |
| 50 | + |
| 51 | +### Documentation Policy [2.v] |
| 52 | + |
| 53 | +All pull requests must resolve related documentation changes before merging. |
| 54 | + |
| 55 | +## Documentation |
| 56 | + |
| 57 | +### Feature Documentation [3.i] |
| 58 | + |
| 59 | +`diagnostic_msgs` has a list of provided [messages and services](README.md). |
| 60 | +New messages and services require their own documentation in order to be added. |
| 61 | + |
| 62 | +### Public API Documentation [3.ii] |
| 63 | + |
| 64 | +`diagnostic_msgs` has embedded API documentation, but it is not currently hosted. |
| 65 | + |
| 66 | +### License [3.iii] |
| 67 | + |
| 68 | +The license for `diagnostic_msgs` is Apache 2.0, the type is declared in the [package.xml](package.xml) manifest file, and a full copy of the license is in the repository level [LICENSE](../LICENSE) file. |
| 69 | + |
| 70 | +There are no source files that are currently copyrighted in this package so files are not checked for abbreviated license statements. |
| 71 | + |
| 72 | +### Copyright Statements [3.iv] |
| 73 | + |
| 74 | +There are no currently copyrighted source files in this package. |
| 75 | + |
| 76 | +## Testing [4] |
| 77 | + |
| 78 | +`diagnostic_msgs` is a package providing strictly message and service definitions and therefore does not require associated tests and has no coverage or performance requirements. |
| 79 | + |
| 80 | +### Linters and Static Analysis [4.v] |
| 81 | + |
| 82 | +`diagnostic_msgs` uses and passes all the standard linters and static analysis tools for its generated C++ and Python code to ensure it follows the [ROS 2 Developer Guide](https://index.ros.org/doc/ros2/Contributing/Developer-Guide/#linters). |
| 83 | + |
| 84 | +Results of the nightly linter tests can be found [here](http://build.ros2.org/view/Epr/job/Epr__common_interfaces__ubuntu_bionic_amd64/lastBuild/testReport/diagnostic_msgs/). |
| 85 | + |
| 86 | +## Dependencies [5] |
| 87 | + |
| 88 | +### Direct Runtime ROS Dependencies [5.i]/[5.ii] |
| 89 | + |
| 90 | +`diagnostic_msgs` has the following runtime ROS dependencies: |
| 91 | +* `builtin_interfaces` |
| 92 | +* `geometry_msgs` |
| 93 | +* `rosidl_default_runtime` |
| 94 | +* `std_msgs` |
| 95 | + |
| 96 | +It has several "buildtool" dependencies, which do not affect the resulting quality of the package, because they do not contribute to the public library API. |
| 97 | + |
| 98 | +### Direct Runtime Non-ROS Dependencies [5.iii] |
| 99 | + |
| 100 | +`diagnostic_msgs` does not have any runtime non-ROS dependencies. |
| 101 | + |
| 102 | +## Platform Support [6] |
| 103 | + |
| 104 | +`diagnostic_msgs` supports all of the tier 1 platforms as described in [REP-2000](https://www.ros.org/reps/rep-2000.html#support-tiers), and tests each change against all of them. |
| 105 | + |
| 106 | +Currently nightly results can be seen here: |
| 107 | +* [linux-aarch64_release](https://ci.ros2.org/view/nightly/job/nightly_linux-aarch64_release/lastBuild/testReport/diagnostic_msgs/) |
| 108 | +* [linux_release](https://ci.ros2.org/view/nightly/job/nightly_linux_release/lastBuild/testReport/diagnostic_msgs/) |
| 109 | +* [mac_osx_release](https://ci.ros2.org/view/nightly/job/nightly_osx_release/lastBuild/testReport/diagnostic_msgs/) |
| 110 | +* [windows_release](https://ci.ros2.org/view/nightly/job/nightly_win_rel/lastBuild/testReport/diagnostic_msgs/) |
| 111 | + |
| 112 | +## Vulnerability Disclosure Policy [7.i] |
| 113 | + |
| 114 | +This package does not yet have a Vulnerability Disclosure Policy |
0 commit comments