Update: Our vulnerability process and bug policy have been approved. You can access a FAQ.
Last update: 22 August 2021
This thread is going to collect requirements for the bug process. It already includes elements from discussions held up until this point.
- external upstream components
- own findings (QA)?
- partners findings
- CVE vulnerability (as upstream)
- CVE vulnerability (as downstream)
Whichever the source of the bug report, it is put in the centralized bug database.
Bugs should be reported against a specific module, but there should be a possibility to link it to another module later. For example, if the initial reporter marked another category, the actual source was found out to be different during a bug fix development etc.
A bug report should include one issue only. If it includes multiple ones, it should be split, and this could be done at any stage of the bug handling.
Bug registration in a system (with source, type)
Are formal reqs meet, categorization, impact analysis, decision for acceptance or rejection => analysis done by an experienced team member
Assigning and prioritizing the bug (may have per-project policy or severity)
- zero-bug policy, so bugs handled before next features
- bug is included as a part of sprint backlog (based on capacity available)
Bug is solved, backporting to LTS and / or other branches
Bug status / documentation / release notes / security advisory is updated.
Bugs’ fixes upstreamed
It should be possible to change the category of the bug, for example change a bug to a security issue or a feature request.
Bugs can be classified on one of the defined severity levels.
- proposed 3 levels: minor, normal, critical
Need to define what classifies as a minor, normal, critical bug.
Open question: how many bug severity levels do we need?
Open question: do we need an SLA for bug fixes (and for which packages?) For example:
- 7 days for critical bugs
- 1 month for normal bugs
- 2 months for minor bugs
The SLA should correspond to the release cycle. For example, if there is a bugfix release every month, the time to fix a normal priority bugs might be of one or two bugfix cycles.
The bug should have a tracking regarding the versions it is present and the versions where it was fixed.
We should be releasing a bugfix versions in regular intervals. However, in case of a high impact bug (eg. security issue) we must be able to release a new bugfix release at any moment.
Our versioning scheme should handle unlimited number of bugfix releases.