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


Gabriele Paoloni
 



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

Join devel@lists.elisa.tech to automatically receive all group messages.