Progress toward Quality Level 1

[ahcorde]

This issue tracks the progression of the package tinydir_vendor that have been deemed necessary for Quality Level 1. It follows the outline described in REP 2004.

1 Version Policy:

• [x] 1.i Must have a version policy (e.g. semver)

• [x] 1.ii Must be at a stable version (e.g. for semver that means version >= 1.0.0)

• [x] 1.iii Must have a strictly declared public API

• [x] 1.iv Must have a policy for API stability

• [x] 1.v Must have a policy for ABI stability

• [x] 1.vi Must have a policy that keeps API and ABI stability within a released ROS distribution

  2 Change Control Process:

  • [x] 2.i Must have all code changes occur through a change request (e.g. pull request, merge request, etc.)
  • [x] 2.ii Must have confirmation of contributor origin (e.g. DCO, CLA, etc.)
  • [x] 2.iii Must have peer review policy for all change requests (e.g. require one or more reviewers)
  • [x] 2.iv Must have Continuous Integration (CI) policy for all change requests
  • [ ] 2.v Must have documentation policy for all change requests

  3 Documentation:

  • [ ] 3.i Must have documentation for each "feature" (e.g. for rclcpp: create a node, publish a message, spin, etc.)

  • [ ] 3.ii Must have documentation for each item in the public API (e.g. functions, classes, etc.)

  • [x] 3.iii Must have a declared license or set of licenses

  • [x] 3.iv Must state copyrights within the project and attribute all authors

  • [ ] 3.v Must have a "quality declaration" document, which declares the quality level and justifies how the package meets each of the requirements

    • [ ] 3.v.a Must have a section in the repository's README which contains the "quality declaration" or links to it
    • [v] 3.v.b Should register with a centralized list of 'Level N' packages, if one exists, to allow for peer review of the claim (counting REP-2005 as such list)
    • [ ] 3.v.c Must reference any 'Level N' lists the package belongs to, and/or any other peer review processes undergone

  4 Testing:

  • [ ] 4.i Must have system tests which cover all items in the "feature" documentation
  • [ ] 4.ii Must have system, integration, and/or unit tests which cover all of the public API

• [x] 4.iii Code Coverage:

  • [x] 4.iii.a Must have code coverage tracking for the package
  • [x] 4.iii.b Must have and enforce a code coverage policy for new changes
  • not required but stating something like "above 95%" as a minimum would be good too (to match developer guide)

• [ ] 4.iv Performance:

  • TBD, not sure it makes sense for a non-runtime cli to try to comply with the performance section
    • [ ] 4.iv.a Must have performance tests (exceptions allowed if they don't make sense to have)
    • [ ] 4.iv.b Must have a performance regression policy (i.e. blocking either changes or releases on unexpected performance regressions)

• [x] 4.v Linters and Static Analysis:

  • [x] 4.v.a Must have a code style and enforce it
  • [x] 4.v.b Must use static analysis tools where applicable
  • although we could integrate a formatter and or tighter analysis like enforcing mypy or else

  5 Dependencies:

  • [ ] Must not have direct runtime "ROS" dependencies which are not at the same level as the package in question ('Level N'), but...
  • [ ] May have optional direct runtime "ROS" dependencies which are not 'Level N', e.g. tracing or debugging features that can be disabled
  • [ ] Must have justification for why each direct runtime "non-ROS" dependency is equivalent to a 'Level N' package in terms of quality

  6 Platform Support:

  • [x] Must support all target platforms for the package's ecosystem. For ROS 2 this means supporting all tier 1 platforms, as defined in REP-2000

    7 Security

  • [x] Must have a declared Vulnerability Disclosure Policy and adhere to a response schedule for addressing security vulnerabilities

[ahcorde]

This package was removed since foxy. Closing this issue