devel@lists.elisa.tech | Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

Home Messages Hashtags Subgroups

Date Date 1 - 20 of 24

Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

Lukas Bulwahn

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.
As an example, we may consider collecting known issues for a few base
Debian base packages and the Linux kernel.

Rationale

Jason proposed to work on some potential quick wins for some users of
Linux distributions.

We want to present a collection of known issues, from existing
databases and resources. The first challenge is to collect and present
the known issues in some way suitable for a discussion and giving a
potential user a chance to understand how to work with such a result.

Planned activities

tbd.
[What type of activities will the working group undertake? What are
the expected results of these activities and how will these be shared
and managed?]

Collaboration

tbd.
[What is the expected relationship with other working groups? How will
the new WG collaborate with the existing WGs, and how will this be
managed?]





Best regards,

Lukas

elana.copperman@...

#1801

Just pulling together a list of known issues from already published sources, has no value.

For this to have any meaning, we need to focus on solutions: Tools, people, corrective actions.

Can ELISA actually support such an endeavor?

Show quoted text

From: devel@... <devel@...> on behalf of Lukas Bulwahn <lukas.bulwahn@...>
Sent: Monday, February 21, 2022 3:09 PM
To: devel@... <devel@...>
Subject: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

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.
As an example, we may consider collecting known issues for a few base
Debian base packages and the Linux kernel.

Rationale

Jason proposed to work on some potential quick wins for some users of
Linux distributions.

We want to present a collection of known issues, from existing
databases and resources. The first challenge is to collect and present
the known issues in some way suitable for a discussion and giving a
potential user a chance to understand how to work with such a result.

Planned activities

tbd.
[What type of activities will the working group undertake? What are
the expected results of these activities and how will these be shared
and managed?]

Collaboration

tbd.
[What is the expected relationship with other working groups? How will
the new WG collaborate with the existing WGs, and how will this be
managed?]

Best regards,

Lukas

Smith, Jason

#1802

Strong disagree.

Review of published bug/defect/anomaly/known issue lists of Software of Unknown Provenance (SOUP) is a normative requirement for several functional- or software-safety standards such as UL 1998, CSA C22.2 No. 0.8, and IEC 62304, so fulfillment of this type of work item would assist manufacturers in compliance with those standards.

I support Lukas’s proposal.

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

Show quoted text

From: devel@... <devel@...> On Behalf Of elana.copperman via lists.elisa.tech
Sent: Monday, February 21, 2022 7:40 AM
To: Lukas Bulwahn <lukas.bulwahn@...>; devel@...
Subject: Re: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

Just pulling together a list of known issues from already published sources, has no value.

For this to have any meaning, we need to focus on solutions: Tools, people, corrective actions.

Can ELISA actually support such an endeavor?

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.

elana.copperman@...

#1803

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards.

It will not help manufacturers in compliance with those standards because no manufacturer will take responsibility to fix those bugs.

Instead, manufacturers will continue to look for alternative solutions which are more practical. For example, SOTIF in the automotive domain.

Show quoted text

From: Smith, Jason <Jason.Smith@...>
Sent: Monday, February 21, 2022 3:41 PM
To: Elana Copperman <Elana.Copperman@...>; Lukas Bulwahn <lukas.bulwahn@...>; devel@...
Subject: RE: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Strong disagree.

I support Lukas’s proposal.

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

Just pulling together a list of known issues from already published sources, has no value.

For this to have any meaning, we need to focus on solutions: Tools, people, corrective actions.

Can ELISA actually support such an endeavor?

Lukas Bulwahn

#1804

On Mon, Feb 21, 2022 at 2:39 PM Elana Copperman
<Elana.Copperman@...> wrote:

Just pulling together a list of known issues from already published sources, has no value.
For this to have any meaning, we need to focus on solutions:  Tools, people, corrective actions.I agree with you, Elana.

Solutions are required:
- Tools to collect, track and evaluate known issues. Every automatic
tool starts with a human understanding the problem and automating the
previous (at least once) human-thought-through steps.
- People to work together requires a dataset, e.g., a list of known
issues, to work together on.
- Corrective actions require a list of known issues to begin with.

It all starts with pulling together a list of known issues from
already published sources.


Lukas

Smith, Jason

#1805

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards.

It will not help manufacturers in compliance with those standards because no manufacturer will take responsibility to fix those bugs.

Instead, manufacturers will continue to look for alternative solutions which are more practical. For example, SOTIF in the automotive domain.

I have no interest in trying to make a case that Linux complies with any kind of safety standard.

It will help manufacturers comply with those standards because those standards do not ask those manufacturers to fix those bugs.

Suggest we talk about this at our next meeting. I don’t have time right now to get into a back-and-forth over e-mail about this.

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

Show quoted text

From: Elana Copperman <Elana.Copperman@...>
Sent: Monday, February 21, 2022 7:48 AM
To: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; devel@...
Subject: RE: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards.

It will not help manufacturers in compliance with those standards because no manufacturer will take responsibility to fix those bugs.

Instead, manufacturers will continue to look for alternative solutions which are more practical. For example, SOTIF in the automotive domain.

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Strong disagree.

I support Lukas’s proposal.

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

Just pulling together a list of known issues from already published sources, has no value.

For this to have any meaning, we need to focus on solutions: Tools, people, corrective actions.

Can ELISA actually support such an endeavor?

Lukas Bulwahn

#1806

On Mon, Feb 21, 2022 at 2:47 PM Elana Copperman <Elana.Copperman@...> wrote:

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards.

It will not help manufacturers in compliance with those standards because no manufacturer will take responsibility to fix those bugs.

Instead, manufacturers will continue to look for alternative solutions which are more practical. For example, SOTIF in the automotive domain.

Elana, so any system using Linux cannot be compliant to any safety standard that requires that for a system element based on Linux to present a list of known issues?

If that is the case, we should write a blog post about this! Many engineers may be interested in that line of thought.

Lukas

elana.copperman@...

#1807

Lukas, that is not what I am saying.

This is the same one sided argument, which ignores market and business needs. And which will inevitably lead to alternative solutions.

If the meeting will be balanced and open to broader consensus/needs, there is potential.

But simply compiling a pretty list from known sources may help with one minor (and as you see, easily resolved) aspect of the standards. It avoids the real complex issues, and has absolutely no practical value for manufacturers.

Show quoted text

From: Lukas Bulwahn <lukas.bulwahn@...>
Sent: Monday, February 21, 2022 3:56 PM
To: Elana Copperman <Elana.Copperman@...>
Cc: Smith, Jason <Jason.Smith@...>; devel@...
Subject: Re: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

On Mon, Feb 21, 2022 at 2:47 PM Elana Copperman <Elana.Copperman@...> wrote:

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards.

It will not help manufacturers in compliance with those standards because no manufacturer will take responsibility to fix those bugs.

Instead, manufacturers will continue to look for alternative solutions which are more practical. For example, SOTIF in the automotive domain.

Elana, so any system using Linux cannot be compliant to any safety standard that requires that for a system element based on Linux to present a list of known issues?

If that is the case, we should write a blog post about this! Many engineers may be interested in that line of thought.

Lukas

Smith, Jason

#1808

Elana, there is need for this. It may not be in your specific area of interest, and if no one else wants to spend time on this because it’s also not in their area of interest, so be it. But there is need for this.

Jason

Show quoted text

From: Elana Copperman <Elana.Copperman@...>
Sent: Monday, February 21, 2022 8:05 AM
To: Lukas Bulwahn <lukas.bulwahn@...>
Cc: Smith, Jason <Jason.Smith@...>; devel@...
Subject: RE: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

Lukas, that is not what I am saying.

This is the same one sided argument, which ignores market and business needs. And which will inevitably lead to alternative solutions.

If the meeting will be balanced and open to broader consensus/needs, there is potential.

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

On Mon, Feb 21, 2022 at 2:47 PM Elana Copperman <Elana.Copperman@...> wrote:

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards.

It will not help manufacturers in compliance with those standards because no manufacturer will take responsibility to fix those bugs.

Instead, manufacturers will continue to look for alternative solutions which are more practical. For example, SOTIF in the automotive domain.

Elana, so any system using Linux cannot be compliant to any safety standard that requires that for a system element based on Linux to present a list of known issues?

If that is the case, we should write a blog post about this! Many engineers may be interested in that line of thought.

Lukas

Gabriele Paoloni

#1809

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....

As an example, we may consider collecting known issues for a few base
Debian base packages and the Linux kernel.

Right now the focus of ELISA has been the Kernel only (also due to BW
limitations) whereas here you intend to extend the scope. Correct?
Also here you mention debian packages, that means to go
looking into a specific distro. It wouldn't be more useful to look
at the upstream projects that correspond to these packages?

e.g. glibc - https://www.gnu.org/software/libc/ or

c++stdlib - https://gcc.gnu.org/onlinedocs/libstdc++/ ?

Otherwise I could point to the Fedora or other free distro specific

bugzillas...but I am afraid it would steer the WG towards specific
distros....

Rationale

Jason proposed to work on some potential quick wins for some users of
Linux distributions.

We want to present a collection of known issues, from existing
databases and resources. The first challenge is to collect and present
the known issues in some way suitable for a discussion and giving a
potential user a chance to understand how to work with such a result.

In the statement above could you expand a bit on "collect and present

the known issues in some way suitable". For example starting from the
Kernel bugzilla or any other bugzilla what would be the added value of
the WG? Maybe an example on a specific issue would hep here...

Thanks

Gab

Planned activities

tbd.
[What type of activities will the working group undertake? What are
the expected results of these activities and how will these be shared
and managed?]

Collaboration

tbd.
[What is the expected relationship with other working groups? How will
the new WG collaborate with the existing WGs, and how will this be
managed?]

Best regards,

Lukas

Lukas Bulwahn

#1810

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....


As an example, we may consider collecting known issues for a few base
Debian base packages and the Linux kernel.
Right now the focus of ELISA has been the Kernel only (also due to BW
limitations) whereas here you intend to extend the scope. Correct?That is correct. As the scope is limited to handling known issues, we
can---even with a small team---probably cover more than just the
kernel; further, the kernel development is certainly the most
challenging upstream project to look into. For the scope extension, I
basically copied the concept of "base packages" from the CIP (Civil
Infrastructure Platform) Project.
They define a "minimal core" by pointing to a few base packages in
Debian; you will probably find (different versions of) those packages
in all other Linux distributions. I just picked Debian as CIP defined
that reference and it is the most 'company-independent' distro as of
now.


Also here you mention debian packages, that means to go
looking into a specific distro. It wouldn't be more useful to look
at the upstream projects that correspond to these packages?
e.g. glibc - https://www.gnu.org/software/libc/ or
 c++stdlib - https://gcc.gnu.org/onlinedocs/libstdc++/ ?
Otherwise I could point to the Fedora or other free distro specific
bugzillas...but I am afraid it would steer the WG towards specific
distros....
I think the first interesting question is how the known issues of the
upstream project and a specific distro package are related.

So, I think it is valid and beneficial to look at both the project and
distro trackers, and see which information is useful to a potential
consumer.

I think it is also fine if you can compile and provide a list from
Fedora and various other distros you care about.


Rationale

Jason proposed to work on some potential quick wins for some users of
Linux distributions.

We want to present a collection of known issues, from existing
databases and resources. The first challenge is to collect and present
the known issues in some way suitable for a discussion and giving a
potential user a chance to understand how to work with such a result.
In the statement above could you expand a bit on "collect and present
the known issues in some way suitable". For example starting from the
Kernel bugzilla or any other bugzilla what would be the added value of
the WG? Maybe an example on a specific issue would hep here...
That is the question to answer. How would such information need to be
presented? Is a manufacturer just interested in the numbers? Do these
findings need to be categorized? What categories would help? What do
the distro bug trackers already offer?

And yes, I think exploring this question on a specific issue will help
to keep the discussion and presentation specific to the problem we
intend to solve for the stakeholders Jason refers to.

Lukas

Thanks
Gab



Planned activities

tbd.
[What type of activities will the working group undertake? What are
the expected results of these activities and how will these be shared
and managed?]

Collaboration

tbd.
[What is the expected relationship with other working groups? How will
the new WG collaborate with the existing WGs, and how will this be
managed?]





Best regards,

Lukas

Lukas Bulwahn

#1811

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

Gabriele Paoloni

#1812

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

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....
>
>>
>> As an example, we may consider collecting known issues for a few base
>> Debian base packages and the Linux kernel.
>
>
> Right now the focus of ELISA has been the Kernel only (also due to BW
> limitations) whereas here you intend to extend the scope. Correct?

That is correct. As the scope is limited to handling known issues, we
can---even with a small team---probably cover more than just the
kernel; further, the kernel development is certainly the most
challenging upstream project to look into. For the scope extension, I
basically copied the concept of "base packages" from the CIP (Civil
Infrastructure Platform) Project.
They define a "minimal core" by pointing to a few base packages in
Debian; you will probably find (different versions of) those packages
in all other Linux distributions. I just picked Debian as CIP defined
that reference and it is the most 'company-independent' distro as of
now.

> Also here you mention debian packages, that means to go
> looking into a specific distro. It wouldn't be more useful to look
> at the upstream projects that correspond to these packages?
> e.g. glibc - https://www.gnu.org/software/libc/ or
> c++stdlib - https://gcc.gnu.org/onlinedocs/libstdc++/ ?
> Otherwise I could point to the Fedora or other free distro specific
> bugzillas...but I am afraid it would steer the WG towards specific
> distros....
>

I think the first interesting question is how the known issues of the
upstream project and a specific distro package are related.

So, I think it is valid and beneficial to look at both the project and
distro trackers, and see which information is useful to a potential
consumer.

I think it is also fine if you can compile and provide a list from
Fedora and various other distros you care about.

>>
>> Rationale
>>
>> Jason proposed to work on some potential quick wins for some users of
>> Linux distributions.
>>
>> We want to present a collection of known issues, from existing
>> databases and resources. The first challenge is to collect and present
>> the known issues in some way suitable for a discussion and giving a
>> potential user a chance to understand how to work with such a result.
>
>
> In the statement above could you expand a bit on "collect and present
> the known issues in some way suitable". For example starting from the
> Kernel bugzilla or any other bugzilla what would be the added value of
> the WG? Maybe an example on a specific issue would hep here...
>

That is the question to answer. How would such information need to be
presented? Is a manufacturer just interested in the numbers? Do these
findings need to be categorized? What categories would help? What do
the distro bug trackers already offer?

And yes, I think exploring this question on a specific issue will help
to keep the discussion and presentation specific to the problem we
intend to solve for the stakeholders Jason refers to.

IMO we should initially spawn an investigation task trying to work on
one or few specific issues and, once we have a better view of the
value the WG can and will provide, we can come back with a more
solid WG proposal....What do you think?

Thanks

Gab

Lukas

> Thanks
> Gab
>
>>
>>
>> Planned activities
>>
>> tbd.
>> [What type of activities will the working group undertake? What are
>> the expected results of these activities and how will these be shared
>> and managed?]
>>
>> Collaboration
>>
>> tbd.
>> [What is the expected relationship with other working groups? How will
>> the new WG collaborate with the existing WGs, and how will this be
>> managed?]
>>
>>
>>
>>
>>
>> Best regards,
>>
>> Lukas
>>
>>
>>
>>
>>

Lukas Bulwahn

#1816

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



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

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....


As an example, we may consider collecting known issues for a few base
Debian base packages and the Linux kernel.
Right now the focus of ELISA has been the Kernel only (also due to BW
limitations) whereas here you intend to extend the scope. Correct?That is correct. As the scope is limited to handling known issues, we
can---even with a small team---probably cover more than just the
kernel; further, the kernel development is certainly the most
challenging upstream project to look into. For the scope extension, I
basically copied the concept of "base packages" from the CIP (Civil
Infrastructure Platform) Project.
They define a "minimal core" by pointing to a few base packages in
Debian; you will probably find (different versions of) those packages
in all other Linux distributions. I just picked Debian as CIP defined
that reference and it is the most 'company-independent' distro as of
now.


Also here you mention debian packages, that means to go
looking into a specific distro. It wouldn't be more useful to look
at the upstream projects that correspond to these packages?
e.g. glibc - https://www.gnu.org/software/libc/ or
 c++stdlib - https://gcc.gnu.org/onlinedocs/libstdc++/ ?
Otherwise I could point to the Fedora or other free distro specific
bugzillas...but I am afraid it would steer the WG towards specific
distros....
I think the first interesting question is how the known issues of the
upstream project and a specific distro package are related.

So, I think it is valid and beneficial to look at both the project and
distro trackers, and see which information is useful to a potential
consumer.

I think it is also fine if you can compile and provide a list from
Fedora and various other distros you care about.


Rationale

Jason proposed to work on some potential quick wins for some users of
Linux distributions.

We want to present a collection of known issues, from existing
databases and resources. The first challenge is to collect and present
the known issues in some way suitable for a discussion and giving a
potential user a chance to understand how to work with such a result.
In the statement above could you expand a bit on "collect and present
the known issues in some way suitable". For example starting from the
Kernel bugzilla or any other bugzilla what would be the added value of
the WG? Maybe an example on a specific issue would hep here...
That is the question to answer. How would such information need to be
presented? Is a manufacturer just interested in the numbers? Do these
findings need to be categorized? What categories would help? What do
the distro bug trackers already offer?

And yes, I think exploring this question on a specific issue will help
to keep the discussion and presentation specific to the problem we
intend to solve for the stakeholders Jason refers to.
IMO we should initially spawn an investigation task trying to work on
one or few specific issues and, once we have a better view of the
value the WG can and will provide, we can come back with a more
solid WG proposal....What do you think?
That sounds like a good strategy. We could call it a "pre-WG setting"
to start with.

For a change, let us start with looking at the known issues of a few
open-source libc libraries, such as:

- GNU C Library (glibc), used in GNU Hurd, GNU/kFreeBSD and Linux
- uclibc-ng, an embedded C library, fork of μClibc, still maintained
- musl, another lightweight C standard library implementation for Linux systems
- Bionic, originally developed by Google for the Android embedded
system operating system, derived from BSD libc

[selected a few libraries from
https://en.wikipedia.org/wiki/C_standard_library that work with Linux
on a hardware with MMU]

We can look at the known issues upstream for the currently latest
versions and the versions shipped by various Linux distros; if they
ship them at all.

Then, we can check what Jason and others expect that one could do with
such information.

If so, anyone interested in just looking into this narrow scope and
then see which next questions may come up?

Lukas

Smith, Jason

#1817

As I implied earlier, I am happy to support this proposal however I can.  Would prefer to get a few of us who are interested in supporting this proposal on a call to discuss further.

Jason

Show quoted text

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Lukas Bulwahn via lists.elisa.tech
Sent: Monday, February 21, 2022 11:46 AM
To: Gabriele Paoloni <gpaoloni@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

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

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

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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2F
github.com%2Felisa-tech%2Fworkgroups%2Fblob%2F61d4beab67c3bc647086
b1db41f0434ec2b98b31%2Fnew-wg-template.md&amp;data=04%7C01%7Cjason
.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd4
5f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpb
GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
6Mn0%3D%7C3000&amp;sdata=z9a389eyiYE6qzabw4oJ9BHWpuM5xi4I9onh8ndRR
T8%3D&amp;reserved=0)

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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2F&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=S3VmA3e1MrQHIyS7tHRH7UF5%2BliJJ%2Baq1zk01r%2BgxY0%3D&amp;reserved=0), if you mean static checker violations it could be a different database....

As an example, we may consider collecting known issues for a few
base Debian base packages and the Linux kernel.
Right now the focus of ELISA has been the Kernel only (also due to
BW
limitations) whereas here you intend to extend the scope. Correct?That is correct. As the scope is limited to handling known issues, we
can---even with a small team---probably cover more than just the
kernel; further, the kernel development is certainly the most
challenging upstream project to look into. For the scope extension, I
basically copied the concept of "base packages" from the CIP (Civil
Infrastructure Platform) Project.
They define a "minimal core" by pointing to a few base packages in
Debian; you will probably find (different versions of) those packages
in all other Linux distributions. I just picked Debian as CIP defined
that reference and it is the most 'company-independent' distro as of
now.

Also here you mention debian packages, that means to go looking
into a specific distro. It wouldn't be more useful to look at the
upstream projects that correspond to these packages?
e.g. glibc -
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Flibc%2F&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xqtwwg2V3TdrCxwLTqDNKdSV396OPuyxo7nOp9foT6E%3D&amp;reserved=0 or  c++stdlib - https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Flibstdc%2B%2B%2F&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=RuHHXUHGIRqFXJs9DVjT0xMCNfZPSKpZ0p9KX5KoEi8%3D&amp;reserved=0 ?
Otherwise I could point to the Fedora or other free distro specific
bugzillas...but I am afraid it would steer the WG towards specific
distros....
I think the first interesting question is how the known issues of the
upstream project and a specific distro package are related.

So, I think it is valid and beneficial to look at both the project
and distro trackers, and see which information is useful to a
potential consumer.

I think it is also fine if you can compile and provide a list from
Fedora and various other distros you care about.

Rationale

Jason proposed to work on some potential quick wins for some users
of Linux distributions.

We want to present a collection of known issues, from existing
databases and resources. The first challenge is to collect and
present the known issues in some way suitable for a discussion and
giving a potential user a chance to understand how to work with such a result.
In the statement above could you expand a bit on "collect and
present the known issues in some way suitable". For example
starting from the Kernel bugzilla or any other bugzilla what would
be the added value of the WG? Maybe an example on a specific issue would hep here...
That is the question to answer. How would such information need to be
presented? Is a manufacturer just interested in the numbers? Do these
findings need to be categorized? What categories would help? What do
the distro bug trackers already offer?

And yes, I think exploring this question on a specific issue will
help to keep the discussion and presentation specific to the problem
we intend to solve for the stakeholders Jason refers to.
IMO we should initially spawn an investigation task trying to work on
one or few specific issues and, once we have a better view of the
value the WG can and will provide, we can come back with a more solid
WG proposal....What do you think?
That sounds like a good strategy. We could call it a "pre-WG setting"
to start with.

For a change, let us start with looking at the known issues of a few open-source libc libraries, such as:

- GNU C Library (glibc), used in GNU Hurd, GNU/kFreeBSD and Linux
- uclibc-ng, an embedded C library, fork of μClibc, still maintained
- musl, another lightweight C standard library implementation for Linux systems
- Bionic, originally developed by Google for the Android embedded system operating system, derived from BSD libc

[selected a few libraries from
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FC_standard_library&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=zvyRBw8lLXVz%2Fm2XZlh%2BPmGCzKsf3k43qotnd9rfckI%3D&amp;reserved=0 that work with Linux on a hardware with MMU]

We can look at the known issues upstream for the currently latest versions and the versions shipped by various Linux distros; if they ship them at all.

Then, we can check what Jason and others expect that one could do with such information.

If so, anyone interested in just looking into this narrow scope and then see which next questions may come up?

Lukas

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.

Oscar Slotosch

#1819

Elena,

I agree with you with respect to Known Bug Handling.

It’s not only about safety compliance but also about social acceptance.

(This is btw the most frustrating aspect of Linux for me, because I cannot

change this unsafe behaviour of the community).

It is ONLY acceptable if an air plane crashes and hundreds of people die

If it can be ensured that the “bug” is analyzed and avoided in future.

So learning from issues is a basic pilar of safety.

Kind regards,

Oscar

SOTIF is an extension of ISO 26262 no replacement.

Von: devel@... <devel@...> Im Auftrag von elana.copperman@...
Gesendet: Montag, 21. Februar 2022 14:48
An: Smith, Jason <Jason.Smith@...>; Lukas Bulwahn <lukas.bulwahn@...>; devel@...
Betreff: Re: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards.

It will not help manufacturers in compliance with those standards because no manufacturer will take responsibility to fix those bugs.

Instead, manufacturers will continue to look for alternative solutions which are more practical. For example, SOTIF in the automotive domain.

Show quoted text

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.

Strong disagree.

I support Lukas’s proposal.

Jason R. Smith, UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)

Distinguished Member of Technical Staff

--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com

Just pulling together a list of known issues from already published sources, has no value.

For this to have any meaning, we need to focus on solutions: Tools, people, corrective actions.

Can ELISA actually support such an endeavor?

Oscar Slotosch

#1820

PS
Count me in on that group, will see how I can contribute.

My vision: 
make bug analysis and fixing a more profitable activity in the community, e.g. by setting up (financial) 
awards (e.g. depending on the bug severity, complexity,..)  for working on KBs. 
Have it financed by forbidding the use of Linux in safety critical systems without paying some fees 
into a the safety activity groups of linux.

-----Ursprüngliche Nachricht-----
Von: devel@... <devel@...> Im Auftrag von Smith, Jason via lists.elisa.tech
Gesendet: Montag, 21. Februar 2022 18:51
An: lukas.bulwahn@...; Gabriele Paoloni <gpaoloni@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

As I implied earlier, I am happy to support this proposal however I can.  Would prefer to get a few of us who are interested in supporting this proposal on a call to discuss further.

Jason

Show quoted text

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Lukas Bulwahn via lists.elisa.tech
Sent: Monday, February 21, 2022 11:46 AM
To: Gabriele Paoloni <gpaoloni@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Interest in a "Known Issues for Release Notes" (Task-Focussed) Working Group

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

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

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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2F
github.com%2Felisa-tech%2Fworkgroups%2Fblob%2F61d4beab67c3bc647086
b1db41f0434ec2b98b31%2Fnew-wg-template.md&amp;data=04%7C01%7Cjason
.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd4
5f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpb
GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
6Mn0%3D%7C3000&amp;sdata=z9a389eyiYE6qzabw4oJ9BHWpuM5xi4I9onh8ndRR
T8%3D&amp;reserved=0)

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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2F&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=S3VmA3e1MrQHIyS7tHRH7UF5%2BliJJ%2Baq1zk01r%2BgxY0%3D&amp;reserved=0), if you mean static checker violations it could be a different database....

As an example, we may consider collecting known issues for a few 
base Debian base packages and the Linux kernel.
Right now the focus of ELISA has been the Kernel only (also due to 
BW
limitations) whereas here you intend to extend the scope. Correct?That is correct. As the scope is limited to handling known issues, we 
can---even with a small team---probably cover more than just the 
kernel; further, the kernel development is certainly the most 
challenging upstream project to look into. For the scope extension, I 
basically copied the concept of "base packages" from the CIP (Civil 
Infrastructure Platform) Project.
They define a "minimal core" by pointing to a few base packages in 
Debian; you will probably find (different versions of) those packages 
in all other Linux distributions. I just picked Debian as CIP defined 
that reference and it is the most 'company-independent' distro as of 
now.

Also here you mention debian packages, that means to go looking 
into a specific distro. It wouldn't be more useful to look at the 
upstream projects that correspond to these packages?
e.g. glibc -
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Flibc%2F&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xqtwwg2V3TdrCxwLTqDNKdSV396OPuyxo7nOp9foT6E%3D&amp;reserved=0 or  c++stdlib - https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Flibstdc%2B%2B%2F&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=RuHHXUHGIRqFXJs9DVjT0xMCNfZPSKpZ0p9KX5KoEi8%3D&amp;reserved=0 ?
Otherwise I could point to the Fedora or other free distro specific 
bugzillas...but I am afraid it would steer the WG towards specific 
distros....
I think the first interesting question is how the known issues of the 
upstream project and a specific distro package are related.

So, I think it is valid and beneficial to look at both the project 
and distro trackers, and see which information is useful to a 
potential consumer.

I think it is also fine if you can compile and provide a list from 
Fedora and various other distros you care about.

Rationale

Jason proposed to work on some potential quick wins for some users 
of Linux distributions.

We want to present a collection of known issues, from existing 
databases and resources. The first challenge is to collect and 
present the known issues in some way suitable for a discussion and 
giving a potential user a chance to understand how to work with such a result.
In the statement above could you expand a bit on "collect and 
present the known issues in some way suitable". For example 
starting from the Kernel bugzilla or any other bugzilla what would 
be the added value of the WG? Maybe an example on a specific issue would hep here...
That is the question to answer. How would such information need to be 
presented? Is a manufacturer just interested in the numbers? Do these 
findings need to be categorized? What categories would help? What do 
the distro bug trackers already offer?

And yes, I think exploring this question on a specific issue will 
help to keep the discussion and presentation specific to the problem 
we intend to solve for the stakeholders Jason refers to.
IMO we should initially spawn an investigation task trying to work on 
one or few specific issues and, once we have a better view of the 
value the WG can and will provide, we can come back with a more solid 
WG proposal....What do you think?
That sounds like a good strategy. We could call it a "pre-WG setting"
to start with.

For a change, let us start with looking at the known issues of a few open-source libc libraries, such as:

- GNU C Library (glibc), used in GNU Hurd, GNU/kFreeBSD and Linux
- uclibc-ng, an embedded C library, fork of μClibc, still maintained
- musl, another lightweight C standard library implementation for Linux systems
- Bionic, originally developed by Google for the Android embedded system operating system, derived from BSD libc

[selected a few libraries from
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FC_standard_library&;data=04%7C01%7Cjason.smith%40ul.com%7C435555b1f5b4493a37a308d9f5621a3c%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637810623962870916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=zvyRBw8lLXVz%2Fm2XZlh%2BPmGCzKsf3k43qotnd9rfckI%3D&amp;reserved=0 that work with Linux on a hardware with MMU]

We can look at the known issues upstream for the currently latest versions and the versions shipped by various Linux distros; if they ship them at all.

Then, we can check what Jason and others expect that one could do with such information.

If so, anyone interested in just looking into this narrow scope and then see which next questions may come up?

Lukas

This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.

Gabriele Paoloni

#1821

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

On Mon, Feb 21, 2022 at 6:08 PM Gabriele Paoloni <gpaoloni@...> wrote:
>
>
>
> On Mon, Feb 21, 2022 at 5:23 PM Lukas Bulwahn <lukas.bulwahn@...> wrote:
>>
>> 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....
>> >
>> >>
>> >> As an example, we may consider collecting known issues for a few base
>> >> Debian base packages and the Linux kernel.
>> >
>> >
>> > Right now the focus of ELISA has been the Kernel only (also due to BW
>> > limitations) whereas here you intend to extend the scope. Correct?
>>
>> That is correct. As the scope is limited to handling known issues, we
>> can---even with a small team---probably cover more than just the
>> kernel; further, the kernel development is certainly the most
>> challenging upstream project to look into. For the scope extension, I
>> basically copied the concept of "base packages" from the CIP (Civil
>> Infrastructure Platform) Project.
>> They define a "minimal core" by pointing to a few base packages in
>> Debian; you will probably find (different versions of) those packages
>> in all other Linux distributions. I just picked Debian as CIP defined
>> that reference and it is the most 'company-independent' distro as of
>> now.
>>
>>
>> > Also here you mention debian packages, that means to go
>> > looking into a specific distro. It wouldn't be more useful to look
>> > at the upstream projects that correspond to these packages?
>> > e.g. glibc - https://www.gnu.org/software/libc/ or
>> > c++stdlib - https://gcc.gnu.org/onlinedocs/libstdc++/ ?
>> > Otherwise I could point to the Fedora or other free distro specific
>> > bugzillas...but I am afraid it would steer the WG towards specific
>> > distros....
>> >
>>
>> I think the first interesting question is how the known issues of the
>> upstream project and a specific distro package are related.
>>
>> So, I think it is valid and beneficial to look at both the project and
>> distro trackers, and see which information is useful to a potential
>> consumer.
>>
>> I think it is also fine if you can compile and provide a list from
>> Fedora and various other distros you care about.
>>
>> >>
>> >> Rationale
>> >>
>> >> Jason proposed to work on some potential quick wins for some users of
>> >> Linux distributions.
>> >>
>> >> We want to present a collection of known issues, from existing
>> >> databases and resources. The first challenge is to collect and present
>> >> the known issues in some way suitable for a discussion and giving a
>> >> potential user a chance to understand how to work with such a result.
>> >
>> >
>> > In the statement above could you expand a bit on "collect and present
>> > the known issues in some way suitable". For example starting from the
>> > Kernel bugzilla or any other bugzilla what would be the added value of
>> > the WG? Maybe an example on a specific issue would hep here...
>> >
>>
>> That is the question to answer. How would such information need to be
>> presented? Is a manufacturer just interested in the numbers? Do these
>> findings need to be categorized? What categories would help? What do
>> the distro bug trackers already offer?
>>
>> And yes, I think exploring this question on a specific issue will help
>> to keep the discussion and presentation specific to the problem we
>> intend to solve for the stakeholders Jason refers to.
>
>
> IMO we should initially spawn an investigation task trying to work on
> one or few specific issues and, once we have a better view of the
> value the WG can and will provide, we can come back with a more
> solid WG proposal....What do you think?
>

That sounds like a good strategy. We could call it a "pre-WG setting"
to start with.

For a change, let us start with looking at the known issues of a few
open-source libc libraries, such as:

- GNU C Library (glibc), used in GNU Hurd, GNU/kFreeBSD and Linux
- uclibc-ng, an embedded C library, fork of μClibc, still maintained
- musl, another lightweight C standard library implementation for Linux systems
- Bionic, originally developed by Google for the Android embedded
system operating system, derived from BSD libc

[selected a few libraries from
https://en.wikipedia.org/wiki/C_standard_library that work with Linux
on a hardware with MMU]

We can look at the known issues upstream for the currently latest
versions and the versions shipped by various Linux distros; if they
ship them at all.

Yes, to be more pragmatic let's for example look at the bugs reported
against the glibc malloc component (pointing to the glibc just because
I am more familiar with it compared to the other library examples)
(https://sourceware.org/bugzilla/buglist.cgi?component=malloc&product=glibc&resolution=---)

In the taskforce kickoff we may want to go over some bug reports
and discuss what we can do with those

Then, we can check what Jason and others expect that one could do with
such information.

If so, anyone interested in just looking into this narrow scope and
then see which next questions may come up?

Yep, so how do we kick-off a kick-off meeting :) ?

Should we Doodle for interest proposing 3 slots to choose amongst?

Thanks

Gab

Lukas

Sudip Mukherjee

#1822

Hi Lukas,

On 21/02/2022 4:23 pm, Lukas Bulwahn wrote:
On Mon, Feb 21, 2022 at 4:01 PM Gabriele Paoloni <gpaoloni@...> wrote:
<snip>



As an example, we may consider collecting known issues for a few base
Debian base packages and the Linux kernel.
Right now the focus of ELISA has been the Kernel only (also due to BW
limitations) whereas here you intend to extend the scope. Correct?That is correct. As the scope is limited to handling known issues, we
can---even with a small team---probably cover more than just the
kernel; further, the kernel development is certainly the most
challenging upstream project to look into. For the scope extension, I
basically copied the concept of "base packages" from the CIP (Civil
Infrastructure Platform) Project.
They define a "minimal core" by pointing to a few base packages in
Debian; you will probably find (different versions of) those packages
in all other Linux distributions. I just picked Debian as CIP defined
that reference and it is the most 'company-independent' distro as of
now.Not really sure why you want to look at Debian packages. iiuc, CIP only
uses Debian as a base for their build runners. But I think the actual
image which is in the product is based on Yocto. Also, if I consider all
the automotive companies I have worked for, I have not seen anyone (yet)
who is using Debian in the car. But again, I have heard of a company
(from a Linkedin recruitment agent) who are planning to use a Debian
based image for the IVI.
But, otoh, being a Debian Developer, I will be very happy if you look
into Debian packages. :)


-- 
Regards
Sudip

Lukas Bulwahn

#1824

On Tue, Feb 22, 2022 at 1:44 PM Sudip Mukherjee
<sudip.mukherjee@...> wrote:

Hi Lukas,

On 21/02/2022 4:23 pm, Lukas Bulwahn wrote:
On Mon, Feb 21, 2022 at 4:01 PM Gabriele Paoloni <gpaoloni@...> wrote:
<snip>



As an example, we may consider collecting known issues for a few base
Debian base packages and the Linux kernel.
Right now the focus of ELISA has been the Kernel only (also due to BW
limitations) whereas here you intend to extend the scope. Correct?That is correct. As the scope is limited to handling known issues, we
can---even with a small team---probably cover more than just the
kernel; further, the kernel development is certainly the most
challenging upstream project to look into. For the scope extension, I
basically copied the concept of "base packages" from the CIP (Civil
Infrastructure Platform) Project.
They define a "minimal core" by pointing to a few base packages in
Debian; you will probably find (different versions of) those packages
in all other Linux distributions. I just picked Debian as CIP defined
that reference and it is the most 'company-independent' distro as of
now.Not really sure why you want to look at Debian packages. iiuc, CIP only
uses Debian as a base for their build runners. But I think the actual
image which is in the product is based on Yocto. Also, if I consider all
the automotive companies I have worked for, I have not seen anyone (yet)
who is using Debian in the car. But again, I have heard of a company
(from a Linkedin recruitment agent) who are planning to use a Debian
based image for the IVI.Well, I think we can settle on looking at the upstream projects first.
The distributions of interest can then be considered in a second
round, among the contributors.

Yocto (in its own words) is not a distribution---so, this means that
the companies just randomly pick arbitrary versions and composition of
packages and ship it. That makes the task of even naming the known
issues almost impossible for anyone outside of the company.

Slowly I am concluding that "taking what CIP defines as core packages"
as a starting point seems to be more difficult than beneficial,
though.

Lukas

But, otoh, being a Debian Developer, I will be very happy if you look
into Debian packages. :)


--
Regards
Sudip

1 - 20 of 24

Previous Topic Next Topic

Home Hashtags Subgroups Terms