QUALITY_DECLARATION

This document is a declaration of software quality for the rmw_dds_common package, based on the guidelines in REP-2004.

<tt>rmw_dds_common</tt> Quality Declaration

The package rmw_dds_common claims to be in the Quality Level 1 category when it is used with a Quality Level 1 middleware.

Below are the rationales, notes, and caveats for this claim, organized by each requirement listed in the Package Requirements for Quality Level 1 in REP-2004.

Version Policy [1]

Version Scheme [1.i]

rmw_dds_common uses semver according to the recommendation for ROS Core packages in the ROS 2 Developer Guide.

Version Stability [1.ii]

rmw_dds_common is 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.

Public API Declaration [1.iii]

All symbols in the installed headers and message files (.msg) 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. All installed message files are in the msg directory of the package.

API Stability Within a Released ROS Distribution [1.iv]/[1.vi]

rmw_dds_common will not break public API within a released ROS distribution, i.e. no major releases once the ROS distribution is released.

ABI Stability Within a Released ROS Distribution [1.v]/[1.vi]

rmw_dds_common contains C and C++ code and therefore must be concerned with ABI stability, and will maintain ABI stability within a ROS distribution.

Change Control Process [2]

rmw_dds_common follows the recommended guidelines for ROS Core packages in the ROS 2 Developer Guide.

Change Requests [2.i]

This package requires that all changes occur through a pull request.

Contributor Origin [2.ii]

This package uses DCO as its confirmation of contributor origin policy. More information can be found in CONTRIBUTING.

Peer Review Policy [2.iii]

Following the recommended guidelines for ROS Core packages, all pull requests must have at least 1 peer review.

Continuous Integration [2.iv]

All pull request must pass CI on all tier 1 platforms

Documentation Policy [2.v]

All pull requests must resolve related documentation changes before merging.

Documentation [3]

Feature Documentation [3.i]

rmw_dds_common has a documented feature list.

Public API Documentation [3.ii]

rmw_dds_common has embedded API documentation. It is not yet hosted publicly.

License [3.iii]

The license for rmw_dds_common 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.

Most recent test results can be found here

Copyright Statements [3.iv]

The copyright holders each provide a statement of copyright in each source code file in rmw_dds_common.

There is an automated test which runs a linter that ensures each file has at least one copyright statement.

The results of the test can be found here.

Testing [4]

Feature Testing [4.i]

Each feature in rmw_dds_common has tests which simulate typical usage, and they are located in the test directory. New features are required to have tests before being added.

Public API Testing [4.ii]

Each part of the public API has tests, which are located in the test directory. New additions or changes to the public API require tests before being added. The tests aim to cover both typical usage and corner cases, but are quantified by contributing to code coverage.

Coverage [4.iii]

rmw_dds_common follows the recommendations for ROS Core packages in the ROS 2 Developer Guide, and opts to use branch coverage instead of line 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

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 here.

A summary of how these statistics are calculated can be found in the ROS 2 On-boarding guide.

Performance [4.iv]

rmw_dds_common follows the recommendations for performance testing of C code in the ROS 2 Developer Guide, and opts to do performance analysis on each release rather than each change.

The performance tests of rmw_dds_common are located in the test/benchmark directory.

Package and system level performance benchmarks that cover features of rmw_dds_common can be found at:

Changes that introduce regressions in performance must be adequately justified in order to be accepted and merged.

Linters and Static Analysis [4.v]

rmw_dds_common uses and passes all the standard linters and static analysis tools for a C++ package as described in the ROS 2 Developer Guide.

Results of the nightly linter tests can be found here.

Dependencies [5]

Direct Runtime ROS Dependencies [5.i]/[5.ii]

rmw_dds_common has the following runtime ROS dependencies which are at Quality Level 1

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.

Direct Runtime Non-ROS Dependencies [5.iii]

rmw_dds_common does not have any runtime non-ROS dependencies.

Platform Support [6]

rmw_dds_common supports all of the tier 1 platforms as described in REP-2000, and tests each change against all of them.

Currently nightly results can be seen here:

Security [7]

Vulnerability Disclosure Policy [7.i]

This package conforms to the Vulnerability Disclosure Policy in REP-2006.

Current status Summary

The chart below compares the requirements in the REP-2004 with the current state of the rmw_dds_common package.

Number

Requirement

Current state

1

Version policy

&#8212;

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

&#8212;

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

&#8212;

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

&#8212;

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

&#8212;

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

&#8212;

6.i

Support targets Tier1 ROS platforms

✓

7

Security

&#8212;

7.i

Vulnerability Disclosure Policy

✓