This document is a declaration of software quality for LTTng (Linux Trace Toolkit: next generation), an external dependency, based on the guidelines in REP-2004.
This quality declaration claims that LTTng is in the Quality Level 1 category.
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.
Note that LTTng itself is split into multiple repositories. Each repository may provide more than one (Debian or other) package.
lttng-tools: components to control LTTng tracinglttng-ust: userspace instrumentation and tracinglttng-modules: Linux kernel instrumentation and tracing
In general, LTTng follows the strict guidelines of the Linux kernel.
Currently, LTTng is used by downstream (ROS) packages through Ubuntu packages. This means that the LTTng version is fixed for a given Ubuntu distro, and thus it is fixed for the corresponding ROS distro(s). If any issue regarding the following requirements arises, it should be possible to fork the LTTng packages, apply a fix, and create and use vendor packages.
The mitigation strategy mentioned in the first section of this document applies here.
LTTng does not declare any versioning scheme, but seems to follow semver.
Upstream issue #1269 tracks the declaration of a formal version scheme.
All LTTng packages are at or above a stable version, i.e. >= 1.0.0.
LTTng packages clearly define their public APIs, which is their installed headers (include/ directories).
API stability within a released ROS distribution is achieved through Ubuntu package restrictions for each distribution.
ABI stability within a released ROS distribution is achieved through Ubuntu package restrictions for each distribution.
All changes occur through the LTTng mailing list or through their code review platform.
LTTng uses DCO as its confirmation of contributor origin policy. For more information, see the documentation on their Gerrit instance.
All commits are signed-off by the author(s) and the reviewer(s).
- https://github.com/lttng/lttng-tools/commits/master
- https://github.com/lttng/lttng-ust/commits/master
- https://github.com/lttng/lttng-modules/commits/master
All changes have at least one peer review.
Most changes are tested on CI before merging.
Release branches and master are periodically tested on their Jenkins instance.
LTTng does not have an explicit documentation policy.
All features which are currently utilized by the dependent packages are documented. If they depend on features which are undocumented, it will be necessary for them to provide their own documentation or contribute it upstream.
Features are listed and well documented on the LTTng website.
LTTng packages have embedded API documentation. It can be viewed on their man pages:
All repositories have a LICENSE file.
All relevant files have a license identifier.
lttng-ustis licensed under LGPLv2.1, the MIT license and GPLv2, seeLICENSEfileliblttng-ust(build dependency) is LGPLv2.1 and MIT- The rest (runtime tools, not dependencies) is GPLv2
lttng-toolsis licensed under LGPLv2.1 and GPLv2, seeLICENSEfileliblttng-ctl(build dependency) is LGPLv2.1- The rest (runtime tools, not dependencies) is GPLv2
lttng-modulesis licensed under LGPLv2.1, GPLv2 and the MIT license, seeLICENSEfile- Not a dependency
All relevant files have a copyright statement and include a list of copyright holders.
LTTng packages have tests in their test/ directories which simulate typical usage.
LTTng packages have tests in their test/ directories which test their public APIs.
LTTng does not have an explicit coverage policy and does not appear to track code coverage. However, that does not impact the quality of dependent packages, because it mostly serves as a metric to show that it is properly tested. Looking at the tests that LTTng has, it does seem to be properly tested. In any case, the mitigation strategy mentioned in the first section of this document applies here if an issue is found.
LTTng does not have an explicit performance regression policy. Some relevant packages have performance tests in the form of benchmarks:
Coverity, cppcheck and scan-build are regularly run against LTTng packages:
- lttng-tools_master_cppcheck
- lttng-tools_master_scan-build
- lttng-tools_master_coverity
- lttng-ust_master_cppcheck
- lttng-ust_master_scan-build
- lttng-ust_master_coverity
- lttng-modules_master_cppcheck
- lttng-modules_master_scan-build
LTTng packages have some direct runtime dependencies, including:
liburcu: userspace RCU (read-copy-update) library
As its name suggests, LTTng only supports Linux-based systems.
LTTng does not have an explicit vulnerability disclosure policy. Upstream issue #1268 tracks the declaration of a formal VDP.
The mitigation strategy mentioned in the first section of this document applies here.
The table below compares the requirements in REP-2004 with the current state of the LTTng package.
| Number | Requirement | Current state |
|---|---|---|
| 1 | Version policy | |
| 1.i | Version policy | ✓ |
| 1.ii | Stable version | ✓ |
| 1.iii | Strictly declared public API | ✓ |
| 1.iv | API stability policy | ✓ |
| 1.v | ABI stability policy | ✓ |
| 1.vi | API/ABI stablility policy within ROS distribution | ✓ |
| 2 | Change control process | |
| 2.i | All changes occur through change request | ✓ |
| 2.ii | Confirmation of contributor origin | ✓ |
| 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 | 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 | ✓ |
| 4.ii | Public API tests | ✓ |
| 4.iii.a | Using coverage | ✓ * |
| 4.iii.b | Coverage policy | ✓ * |
| 4.iv.a | Performance tests | ✓ |
| 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 lower level ROS dependencies | ✓ |
| 5.ii | Optional ROS lower level dependencies | ✓ |
| 5.iii | Justifies quality use of non-ROS dependencies | ✓ * |
| 6 | Platform Support | |
| 6.i | Support targets tier 1 ROS platforms | ✓ |
| 7 | Security | |
| 7.i | Vulnerability Disclosure Policy | ✓ * |
* : mitigated/does not apply
Comparing this table to the Quality Level Comparison Chart of REP-2004 led us to conclude that this package qualifies for Quality Level 1.