Declare Quality Level 3

[bmagyar]

• [ ] Version Policy:
  • [x] Must have a version policy (e.g. semver)
  • [ ] Must be at a stable version (e.g. for semver that means version >= 1.0.0)
• [x] Change Control Process:
  • [x] Must have all code changes occur through a change request (e.g. pull request, merge request, etc.)
  • [x] Must have Continuous Integration (CI) policy for all change requests
• [ ] Documentation:
  • [x] Must have a declared license or set of licenses
  • [x] Must state copyrights within the project and attribute all authors
  • [ ] May have a "quality declaration" document, which declares the quality level and justifies how the package meets each of the requirements
  • [ ] Must have a section in the repository's README which contains the "quality declaration" or links to it
  • [ ] May register with a centralized list of 'Level 3' packages, if one exists, to allow for peer review of the claim
  • [ ] Must reference any 'Level 3' lists the package belongs to, and/or any other peer review processes undergone
• [x] Testing: No explicit testing requirements, though covering some if not all of the features with tests is recommended
• [ ] Dependencies: May have direct runtime "ROS" dependencies which are not 'Level 3' dependencies, but they should still be documented in the quality declaration
• [ ] Platform Support: 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
• [ ] Security Should have a declared Vulnerability Disclosure Policy and adhere to a response schedule for addressing security vulnerabilities

[bmagyar]

I'll go ahead and tick the ones I think we already meet.

Let me start scrutinizing the rest.

Must have a version policy (e.g. semver)

Have how? ROS already uses the three-number semver structure, do we need to add a declaration of this? I don't see what else we could change to meet this.

Testing

Maybe it's just my opinion but I'd not give anyone any quality level without some test coverage. C'mon guys

Dependencies

control_toolbox and realtime_tools probably quality as runtime dependencies but they should probably be very close to level 3 as well.

Platform Support

Always fully covering all of Tier1 is unrealistic. Even the buildfarm I have access to as a maintainer only handles Linux builds. There is no feedback for Windows of macOS, having them in Tier1 feels more like a wish from OR, not something that can be realistically realized by others without infrastructure. @Karsten1987 how is this done in other packages without their own buildfarm?

Security

Sure, ethical hackers wouldn't know how to report vulnerabilities without a lengthy document that they will surely read. ;) Where does this come from? Do we just copy https://ros.org/reps/rep-2006.html and change the email address?

[gavanderhoorn]

Must have a version policy (e.g. semver)

Have how? ROS already uses the three-number semver structure, do we need to add a declaration of this? I don't see what else we could change to meet this.

using a triplet as a version number != following and practicing semantic versioning.

semver.org is pretty specific about it:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

I believe that's what REP-2004 refers to.

[destogl]

Pinky promise: I will add templates for Issues and PRs