On Mon, Feb 21, 2022 at 4:01 PM Gabriele Paoloni <gpaoloni@...> wrote:

Hi Lukas

On Mon, Feb 21, 2022 at 2:12 PM Lukas Bulwahn <lukas.bulwahn@...> wrote:

Dear all,


(Using the 'New working group proposal template' from
https://github.com/elisa-tech/workgroups/blob/61d4beab67c3bc647086b1db41f0434ec2b98b31/new-wg-template.md)


Proposed working group name

Known Issues for Release Notes Working Group

Proposed WG chair

tbd.

Proposed meeting schedule

Let us start with a denser schedule, twice a week to get momentum
going. Then once the tasks are clear, we can continue with a shorter
meeting every two weeks or so.

Specific meeting date and time to be determined by vote among
interested participants.

Proposed mission statement

What is the proposed scope of the workgroup? Will it focus on a
specific aspect of the ELISA mission statement, or a specific industry
sector or type of safety use case for Linux?

The goal of this working group is to produce a collection of known
issues of a Linux distribution.

Can you specify what you mean by "known issue"?
IMO it is a bit vague. For example if you mean bug I could think of
the kernel bugzilla (https://bugzilla.kernel.org/), if you mean static
checker violations it could be a different database....

Sorry, I missed to answer this question in my previous email.

The point above is the critical first task for a group to agree on.

ISO 26262 mentions: "the reactions of the functions under anomalous
operating conditions" and "a description of known anomalies"; and it
defines anomaly as "condition that deviates from expectations based on
requirements specifications, design documents, user documents,
standards, etc., or from someone’s perceptions or experiences".

Both could well be covered by the term "known issues". Other standards
might have different formulations to refer to a similar concept.

I am also fine to include 'failing tests'; that is probably pretty
close to the definition of known issues above.

I am also fine to include 'static checker violations' (or compiler
warnings)---with which we are moving a bit away from the definition
above---but if you live up to the professional standard of writing
warning-free code, I guess a code with a compiler warnings deviates
from your standard. I agree the source and database are different and
probably the "corresponding work-around measures" (in terms of ISO
26262) may be different here to other classes of known issues.

All of this can be pretty well explored with some examples that are
just sitting there to be picked up in various open-source packages.


Lukas