Security and safety engineering, as well as quality management, share a common goal: Avoiding or eliminating bugs and complete bug classes in software. Hence, these fields of engineering may share methods, tools, well-known best practices, and development efforts during the software development. However, these fields of engineering also have
different (partly competing) goals and priorities. Understanding these different goals and priorities of different stakeholders can be summarized as “A bug is NOT a bug is NOT a bug”.
Let us go through what is there in the kernel community and discuss alignment of on-going and future work, in a structured moderated way.
In this discussion, I would like to touch on:
- Various attempts of defining “a bug” and its implications
- Classifying “bugs” into bug classes
- Assessing suitable bug tracking methods, tools and best practices for different bug classes.
- Assessing impact for different bug classes and decisions in follow-up work to the bug fixing that may be taken depending on the bugs’ impact and the stakeholders’ priorities.