Release criteria checklist - Release D

This page contains a table with criteria and some notes on what the PTL and commiters need to check as part of release preparation. It is influenced by CII badging criteria CII status: near-RT RIC.

Release Criteria (RC) headline	Criteria details/references
RC-1 PTL: Check that we have a release summary. Committers: check that release notes are updated in RST file in gerrit.	OK PTL created this summary (under "Achieved D release highlights = high-level release notes" in D release (Jul 2021)) as per copy of per-component release notes (see attachment to this page) and as per JIRA items that we marked as "done" (link).
RC-2: Check that we have all fixed security bugs listed in release notes	OK As of 2021-06-24, there were no security bugs reported as per this filter.
RC-3: Save one-time snapshots of some reports	OK (1) The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix (link): 7 items open (I assume the ones that are closed are handled well). RIC-799, RIC-772, RIC-653, RIC-634 are all raised from within the project (and therefore implicitly acknoledged. For RIC-757, RIC-570 I asked for further information. OK (2) The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive): link. I am not aware of external feature request raised towards near-RT RIC. Instructions are updated here under "New feature requests": Tools (mailing list, JIRA, Gerrit) OK (3) The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days: No vulnerability reports received (see filter) OK (4) code coverage report from last meeting minutes - meeting minutes from 2021-06-22 contain the summary. The report snapshots are in version 2 of coverage.zip in the attachments of this wiki page: Code coverage reports
RC-4: Check (from meeting notes) that we checked for all L and XL commits that they include unit tests	OK This was done on 2021-06-22, 2021-05-25, 2021-04-27, 2021-03-16 (we took this practice into use in March 2021)
RC-5: Check that "blocker" code smells in Sonartype have been addressed	OK Check Sonartype report export and store that export into wiki page: The report snapshots are in version 2 of coverage.zip in the attachments of this wiki page: Code coverage reports