rcl_logging_spdlog
master
Implementation of rcl_logging API for an spdlog backend.
|
This document is a declaration of software quality for the rcl_logging_spdlog
package, based on the guidelines in REP-2004.
The package rcl_logging_spdlog
claims to be in the Quality Level 4 category.
Below are the rationales, notes, and caveats for this claim, organized by each requirement listed in the Package Quality Categories in REP-2004 of the ROS2 developer guide.
rcl_logging_spdlog
uses semver
according to the recommendation for ROS Core packages in the ROS 2 Developer Guide.
Currently this package it is not at or above a stable version, i.e. >= 1.0.0
.
All symbols in the installed headers are considered part of the public API.
All installed headers are in the include directory of the package, headers in any other folders are not installed and considered private.
rcl_logging_spdlog
will not break public API within a released ROS distribution, i.e. no major releases once the ROS distribution is released.
rcl_logging_spdlog
contains C code and therefore must be concerned with ABI stability, and will maintain ABI stability within a ROS distribution.
rcl_logging_spdlog
will not break API nor ABI within a released ROS distribution, i.e. no major releases once the ROS distribution is released.
rcl_logging_spdlog
follows the recommended guidelines for ROS Core packages in the ROS 2 Developer Guide.
All changes will occur through a pull request, check ROS 2 Developer Guide for additional information.
This package uses DCO as its confirmation of contributor origin policy. More information can be found in ../CONTRIBUTING.md "CONTRIBUTING"
Following the recommended guidelines in the ROS 2 Developer Guide all pull requests must have at least 1 peer review.
All pull requests must pass CI on all tier 1 platforms
Currently nightly results can be seen here:
All pull requests must resolve related documentation changes before merging.
rcl_logging_spdlog
does not have feature documentation.
rcl_logging_spdlog
does not have public API documentation.
The license for rcl_logging_spdlog
is Apache 2.0, and a summary is in each source file, the type is declared in the package.xml
manifest file, and a full copy of the license is in the LICENSE
file.
There is an automated test which runs a linter that ensures each file has a license statement. Here can be found a list with the latest results of the various linters being run on the package.
The copyright holders each provide a statement of copyright in each source code file in rcl_logging_spdlog
.
There is an automated test which runs a linter that ensures each file has at least one copyright statement. Latest linter result report can be seen here.
rcl_logging_spdlog
does not include feature testing.
rcl_logging_spdlog
does not include Public API testing.
rcl_logging_spdlog
does not include tests, so coverage is not provided.
rcl_logging_spdlog
does not conduct performance tests.
rcl_logging_spdlog
uses and passes all the standard linters and static analysis tools for a C package as described in the ROS 2 Developer Guide. Passing implies there are no linter/static errors when testing against CI of supported platforms.
Currently nightly results can be seen here:
Below are evaluations of each of rcl_logging_spdlog
's run-time and build-time dependencies that have been determined to influence the quality.
rcl_logging_spdlog
depends on the ROS packages rcutils
and spdlog_vendor
.
rcutils
was declared to be Quality Level 4 here.
spdlog_vendor
was declared to be Quality Level 4 here.
rcl_logging_spdlog
has no optional Direct Runtime ROS dependencies that need to be considered for this declaration.
rcl_logging_spdlog
has a Direct Runtime non-ROS dependenciy the spdlog
library. It was declared to be Quality Level 4 here.
rcl_logging_spdlog
supports all of the tier 1 platforms as described in REP-2000, and tests each change against all of them.
This package conforms to the Vulnerability Disclosure Policy in REP-2006.
The chart below compares the requirements in the REP-2004 with the current state of the rcl
package.
Number | Requirement | Current state |
---|---|---|
1 | Version policy | — |
1.i | Version Policy available | ✓ |
1.ii | Stable version | ☓ |
1.iii | Declared public API | ✓ |
1.iv | API stability policy | ✓ |
1.v | ABI stability policy | ✓ |
1.vi_ | API/ABI stable within ros distribution | ✓ |
2 | Change control process | — |
2.i | All changes occur on change request | ✓ |
2.ii | Contributor origin (DCO, CLA, etc) | ✓ |
2.iii | Peer review policy | ✓ |
2.iv | CI policy for change requests | ✓ |
2.v | Documentation policy for change requests | ✓ |
3 | Documentation | — |
3.i | Per feature documentation | ☓ |
3.ii | Per public API item documentation | ☓ |
3.iii | Declared License(s) | ✓ |
3.iv | Copyright in source files | ✓ |
3.v.a | Quality declaration linked to README | ✓ |
3.v.b | Centralized declaration available for peer review | ✓ |
4 | Testing | — |
4.i | Feature items tests | ☓ |
4.ii | Public API tests | ☓ |
4.iii.a | Using coverage | ☓ |
4.iii.a | Coverage policy | ☓ |
4.iv.a | Performance tests (if applicable) | ☓ |
4.iv.b | Performance tests policy | ✓ |
4.v.a | Code style enforcement (linters) | ✓ |
4.v.b | Use of static analysis tools | ✓ |
5 | Dependencies | — |
5.i | Must not have ROS lower level dependencies | ✓ |
5.ii | Optional ROS lower level dependencies | ✓ |
5.iii | Justifies quality use of non-ROS dependencies | ✓ |
6 | Platform support | — |
6.i | Support targets Tier1 ROS platforms | ✓ |
7 | Security | — |
7.i | Vulnerability Disclosure Policy | ☓ |