This document is a declaration of software quality for the email package, based on the guidelines in REP-2004.
The package email 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.
email uses semver according to the recommendation for ROS Core packages in the ROS 2 Developer Guide.
email is not yet at a stable version, i.e. < 1.0.0.
The current version can be found in its package.xml, and its change history can be found in its CHANGELOG.
All symbols in the installed headers that are declared with EMAIL_PUBLIC are considered part of the public API.
email could break public API within a released ROS distribution, i.e. there might be major releases once the ROS distribution is released.
email contains C++ code and therefore must be concerned with ABI stability, and might not maintain ABI stability within a ROS distribution.
email follows most of 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. There is an automated DCO check for change requests. More information can be found in CONTRIBUTING.
Not all pull requests are currently peer-reviewed.
All pull requests must pass CI on Ubuntu.
All pull requests must resolve related documentation changes before merging.
email has a feature list and each item in the list links to the corresponding feature documentation.
There is documentation for all of the features, and new features require documentation before being added.
email's API is publicly available.
The license for email 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 using ament_copyright through ament_lint_common that ensures each file has a license statement.
The copyright holders each provide a statement of copyright in each source code file in email.
There is an automated test using ament_copyright through ament_lint_common that ensures each file has a license statement.
Not all features in email currently have tests which simulate typical usage.
Some tests are located in the test directory.
Not all parts of the public API have tests.
Some tests are located in the test directory.
The tests aim to cover both typical usage and corner cases, but are quantified by contributing to code coverage.
email tries to follow the recommendations for ROS Core packages in the ROS 2 Developer Guide, and opts to use line coverage instead of branch coverage.
This includes:
- tracking and reporting line coverage statistics
- achieving and maintaining a reasonable branch line coverage (90-100%)
- no lines are manually skipped in coverage calculations (unless it is for technical reasons)
Changes are required to make a best effort to keep or increase coverage before being accepted, but decreases are allowed if properly justified and accepted by reviewers.
Current coverage statistics can be viewed here and in the latest Test workflow.
email has a line coverage >= 90%, which is calculated over all non-test directories within email.
email has no performance tests.
email uses and passes all the ROS 2 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, the latest test results can be seen here.
Below are evaluations of each of email's run-time and build-time dependencies that have been determined to influence the quality.
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.
It also has several test dependencies, which do not affect the resulting quality of the package, because they are only used to build and run the test code.
email has the following runtime ROS dependencies:
The rcpputils package provides an API which contains common utilities and data structures useful when programming in C++.
It is Quality Level 1, see its Quality Declaration document.
The rcutils package provides an API which contains common utilities and data structures useful when programming in C.
It is Quality Level 1, see its Quality Declaration document.
email has the following run-time or build-time dependencies:
The libcurl library provides a C API for multiprotocol file transfer.
It currently has no quality declaration.
The yaml-cpp library, possibly through the yaml_cpp_vendor package, provides an API for parsing and emitting YAML in C++.
It currently has no quality declaration.
email does not currently officially support all of the tier 1 platforms as described in REP-2000.
This package has no formal Vulnerability Disclosure Policy, but it will try to conform to the policy described in REP-2006.
Use the email address available on the profile of the owner of this repository.
Submit your vulnerability report using email directly or using ROS 2 with rmw_email_cpp by publishing a std_msgs/String message.
The table below compares the requirements in REP-2004 with the current state of the email package.
| Number | Requirement | Current state |
|---|---|---|
| 1 | Version policy | |
| 1.i | Version policy | ✓ |
| 1.ii | Stable version | x |
| 1.iii | Strictly declared public API | ✓ |
| 1.iv | API stability policy | x |
| 1.v | ABI stability policy | x |
| 1.vi | API/ABI stablility policy within ROS distribution | x |
| 2 | Change control process | |
| 2.i | All changes occur through change request | ✓ |
| 2.ii | Confirmation of contributor origin | ✓ |
| 2.iii | Peer review policy | x |
| 2.iv | CI policy for change requests | ✓ |
| 2.v | Documentation policy for change requests | ✓ |
| 3 | Documentation | |
| 3.i | Per feature documentation | ✓ |
| 3.ii | Public API documentation | ✓ |
| 3.iii | Declared license(s) | ✓ |
| 3.iv | Copyright in source files | ✓ |
| 3.v.a | Quality declaration linked to from README | ✓ |
| 3.v.b | Centralized declaration available for peer review | |
| 3.v.c | References any Level N lists the package belongs to | ✓ |
| 4 | Testing | |
| 4.i | Feature items tests | x |
| 4.ii | Public API tests | x |
| 4.iii.a | Using coverage | ✓ |
| 4.iii.b | Coverage policy | ✓ |
| 4.iv.a | Performance tests | x |
| 4.iv.b | Performance tests policy | x |
| 4.v.a | Code style enforcement (linters) | ✓ |
| 4.v.b | Use of static analysis tools | ✓ |
| 5 | Dependencies | |
| 5.i | Must not have lower level ROS dependencies | ✓ |
| 5.ii | Optional ROS lower level dependencies | ✓ |
| 5.iii | Justifies quality use of non-ROS dependencies | x * |
| 6 | Platform Support | |
| 6.i | Support targets tier 1 ROS platforms | x |
| 7 | Security | |
| 7.i | Vulnerability Disclosure Policy | x |
Comparing this table to the Quality Level Comparison Chart of REP-2004 led us to conclude that this package qualifies for Quality Level 4.