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