doc: release: Document release quality metrics

Document the bug count metrics used to gate the release process

Signed-off-by: David Leach <david.leach@nxp.com>
This commit is contained in:
David Leach 2020-06-17 15:45:31 -05:00 committed by Anas Nashif
commit 5385d49029

View file

@ -76,7 +76,8 @@ any time).
As fixes make their way into the mainline, the patch rate will slow over time.
The mainline release owner releases new -rc drops once or twice a week; a normal
series will get up to somewhere between -rc4 and -rc6 before the code base is
considered to be sufficiently stable and the final 0.4.x release is made.
considered to be sufficiently stable and the quality metrics have been achieved
at which point the final 0.4.x release is made.
At that point, the whole process starts over again.
@ -98,6 +99,25 @@ Here is the description of the various moderation levels:
- Bug Fixes: P1 and P2
- Documentation + Test Coverage
Release Quality Criteria
************************
The current backlog of prioritized bugs shall be used as a quality metric to
gate the final release. The following counts shall be used:
.. csv-table:: Bug Count Release Thresholds
:header: "High", "Medium", "Low"
:widths: auto
"0","<20","<50"
.. note::
The "low" bug count target of <50 will be a phased appoach starting with 150
for release 2.4.0, 100 for release 2.5.0, and 50 for release 2.6.0
Releases
*********
@ -126,7 +146,6 @@ The following syntax should be used for releases and tags in Git:
Zephyr Code and Releases
Long Term Support (LTS)
=======================