Date   

Re: Presentation on AGL and ELISA collaboration: AGL base for Instrument Cluster & IVI telltales safety function

Lukas Bulwahn
 

Dear Naoto-san,

Thank for you for your presentation and your response and thank you for further interacting with our group.


Last week, I presented IC-EG architecture. ICーEG started to aim with the
developing a real cluster platform. IC-EG plans to release first code about
September 2020.
We are looking forward to your first release and we are happy to employ the envisioned quality assurance and measurement methods on your kernel release and configuration. I hope this information will support to build a high-quality cluster platform and will motivate you to use these methods, acknowledge the value of our work, and support and contribute to the advance of those methods.


Lukas


REMINDER: Complete Poll to Determine Weekly Date/Time for ELISA Development-Process Calls - Due Monday December 2nd

Min Yu
 

Thank-you to those who have indicated your availabilities. If you haven't, please complete the poll by 5pm ET, Monday, December 2nd. 


Regards,
Min
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


On Mon, Nov 25, 2019 at 9:52 AM Min Yu <myu@...> wrote:
Thanks for those who have already joined the development-process mailing list. It's great to see the momentum. For those who haven't but are interested, please see the email below for instructions on how to join an ELISA mailing list (or subgroup). 

And please take a minute to complete the poll below to help us determine the best date/time to hold the weekly meetings for the group:


On Fri, Nov 22, 2019 at 11:58 AM Min Yu <myu@...> wrote:
Following today's ELISA weekly sync call, the development-process mailing list has been created: https://lists.elisa.tech/g/development-process

If you are interested and wish to participate in this group's discussion, please join the group and here are the instructions on how to self-subscribe: 
  • Log into https://lists.elisa.tech/g/main
  • Click on Subgroups to the left and this will display the list of available subgroups for ELISA 
  • Navigate to the development-process page
  • Click +Join This Group toward the near bottom of the page and this will add you to the group.
Please reach out if you have any questions.
Min
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


Complete Poll to Determine Weekly Date/Time for ELISA Development-Process Calls - Due Monday December 2nd

Min Yu
 

Thanks for those who have already joined the development-process mailing list. It's great to see the momentum. For those who haven't but are interested, please see the email below for instructions on how to join an ELISA mailing list (or subgroup). 

And please take a minute to complete the poll below to help us determine the best date/time to hold the weekly meetings for the group:


On Fri, Nov 22, 2019 at 11:58 AM Min Yu <myu@...> wrote:
Following today's ELISA weekly sync call, the development-process mailing list has been created: https://lists.elisa.tech/g/development-process

If you are interested and wish to participate in this group's discussion, please join the group and here are the instructions on how to self-subscribe: 
  • Log into https://lists.elisa.tech/g/main
  • Click on Subgroups to the left and this will display the list of available subgroups for ELISA 
  • Navigate to the development-process page
  • Click +Join This Group toward the near bottom of the page and this will add you to the group.
Please reach out if you have any questions.
Min
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


Please join development-process Mailing List if Interested in Participating and Contributing

Min Yu
 

Following today's ELISA weekly sync call, the development-process mailing list has been created: https://lists.elisa.tech/g/development-process

If you are interested and wish to participate in this group's discussion, please join the group and here are the instructions on how to self-subscribe: 
  • Log into https://lists.elisa.tech/g/main
  • Click on Subgroups to the left and this will display the list of available subgroups for ELISA 
  • Navigate to the development-process page
  • Click +Join This Group toward the near bottom of the page and this will add you to the group.
Please reach out if you have any questions.
Min
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


Re: Presentation on AGL and ELISA collaboration: AGL base for Instrument Cluster & IVI telltales safety function

Lukas Bulwahn
 

Thanks, Jan Simon.

 

This REALLY helps A LOT to get started.

 

Lukas

 

Von: devel@... [mailto:devel@...] Im Auftrag von Jan Simon Moeller
Gesendet: Freitag, 22. November 2019 13:14
An: i33399_yamaguchi@...
Cc: Bulwahn Lukas, JC-20 <Lukas.Bulwahn@...>; devel@...; myu@...
Betreff: Re: [ELISA Technical Community] Presentation on AGL and ELISA collaboration: AGL base for Instrument Cluster & IVI telltales safety function

 

Hi Yamaguchi-san & Lukas,

 

Let me propose something:

 

>- Following AGL's mantra "Code First", where can we find the repository in which you define the Linux kernel for the AGL instrument cluster?

 

Maybe as an intermediate starting point look at the current kernel/recipe that is used for the Instrument Cluster POC for CES. The reason I bring this up is that we could work on possible FUSA requirements that need changes to the sources, documentation or workflow upfront. So when we enter the next phase in 2020 we won't have to go back and 'fix' things in retrospective (doc or workflow for now).

 

IIRC the current PoC targets a Rcar-E3 SoC from Renesas similar or equal to https://elinux.org/R-Car/Boards/Ebisu .

 

The kernel comes (as for all Rcar-*3) out of the

 

which we slightly 'impedance-match' to AGL (topmost commits), add config options and host at

 

More specifically the kernel recipe is:

 

A prepatched kernel-tree is here:

The kernel .config  (IVI config set, not IC config set!)  is here:

 

Keep in mind, this means the kernel is *not* tailored for the intended IC use-case in terms of config options and such, but it is a start for discussing what we have or (will) need. The tailored configuration and new kernel can be provided by the IC-EG later on as we go. I'm pretty sure the kernel is the same but with less options enabled of course.

 

Again, this might not be the final platform, kernel or config. But we'll have a starting point and learn as we go.

 

HTH!

 

Best,

Jan-Simon

 


Re: Presentation on AGL and ELISA collaboration: AGL base for Instrument Cluster & IVI telltales safety function

Jan Simon Moeller
 

Hi Yamaguchi-san & Lukas,

Let me propose something:

>- Following AGL's mantra "Code First", where can we find the repository in which you define the Linux kernel for the AGL instrument cluster?


Maybe as an intermediate starting point look at the current kernel/recipe that is used for the Instrument Cluster POC for CES. The reason I bring this up is that we could work on possible FUSA requirements that need changes to the sources, documentation or workflow upfront. So when we enter the next phase in 2020 we won't have to go back and 'fix' things in retrospective (doc or workflow for now).

IIRC the current PoC targets a Rcar-E3 SoC from Renesas similar or equal to https://elinux.org/R-Car/Boards/Ebisu .

The kernel comes (as for all Rcar-*3) out of the

which we slightly 'impedance-match' to AGL (topmost commits), add config options and host at

More specifically the kernel recipe is:

A prepatched kernel-tree is here:
The kernel .config  (IVI config set, not IC config set!)  is here:

Keep in mind, this means the kernel is *not* tailored for the intended IC use-case in terms of config options and such, but it is a start for discussing what we have or (will) need. The tailored configuration and new kernel can be provided by the IC-EG later on as we go. I'm pretty sure the kernel is the same but with less options enabled of course.

Again, this might not be the final platform, kernel or config. But we'll have a starting point and learn as we go.

HTH!

Best,
Jan-Simon


Re: Presentation on AGL and ELISA collaboration: AGL base for Instrument Cluster & IVI telltales safety function

i33399_yamaguchi@...
 

Hi Lukas

Sorry to delay response. I missed the email.

- Following AGL's mantra "Code First", where can we find the repository in which you define the Linux kernel for the AGL instrument cluster?
Current AGL Cluster target is only demo use. It was developed before starting IC-EG. It is not including safety and QM isolation futures.

Last week, I presented IC-EG architecture. ICーEG started to aim with the developing a real cluster platform. IC-EG plans to release first code about September 2020.
Currently, we try to prove the QM Isolation concept.

Lucas taught us the need to share kernel versions and configs at last week's meeting. The same is true for user space libraries that require quality.
I agree with this opinion. This issue was shared with IC-EG. But this topic is not including in current AGL UCB. We will tackle this issue from now on, and will reflect to first code release.


- To your slide "Case study : Telltale", I would like to know a bit more details:
We will share this in EG.

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Senior Specialist Doctor of Infomatics
Software Fundamental Technology Group
Software Development Department I
Electronics Division
AISIN AW CO.,LTD.
YAMAGUCHI Naoto
E-mail: i33399_YAMAGUCHI@...
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


-----Original Message-----
From: devel@... [mailto:devel@...] On Behalf Of Lukas Bulwahn
Sent: Friday, November 15, 2019 10:16 PM
To: devel@...; I33399 Yamaguchi Naoto
Cc: myu@...
Subject: Re: [ELISA Technical Community] Presentation on AGL and ELISA collaboration: AGL base for Instrument Cluster & IVI telltales safety function

Dear Naoto-san,

At ELISA, we are all happy to help and use the "Linux kernel for the AGL instrument cluster" as an object of investigation and the telltales safety function as use case for discussion.

To do so, we need a bit more information to get started. So, I would like to immediately kick off the discussion here with the following questions:

- Following AGL's mantra "Code First", where can we find the repository in which you define the Linux kernel for the AGL instrument cluster?

A pointer to the bitbake recipe in a AGL git repository would be great. Then, we can build the Linux kernel for the AGL instrument cluster for our investigation purpose. If you have not decided for a different kernel than the AGL unified base or have not created a separate config for the AGL instrument cluster, a confirmation that using the IVI kernel and the IVI config from AGL is a good way to continue the investigation for now would be great. Also, it would be good to know if and when you plan to provide a dedicated kernel and kernel config for the instrument cluster.

- To your slide "Case study : Telltale", I would like to know a bit more details:

- What is the safety requirement of the telltale functionality exactly?
- What is the "fail-safe" state of the overall system?
- How is this safety requirement assumed to be broken down to the different components?

I can see different ways of breaking down the requirements, some break-downs require less requirements on the overall systems, other break-downs might require availability requirements of some system elements, which are really difficult to achieve.

I am happy to assist in structuring the description of the use case to allow the group in ELISA to understand the requirements towards the Linux kernel.

Thanks for helping us to get together and figuring out how ELISA can contribute to your working group.


Best regards,

Lukas


Advent Presentation @ Validas: Safety Plan for Linux Qualification

Oscar Slotosch
 

Hello,

now we have the beautiful invitation for all interested persons who happen to stay in Munich on December 4th at 4 PM (16:00)

We will record the talk (not sure if we can stream it live).

 

Hoping to see many from you at Validas

 

Kind regards,

                Oscar

 

--

Enjoy our new podcast: Tool and Library Qualification at http://www.validas.de/en/podcast/

--

Validas AG

Dr. Oscar Slotosch

Vorstand

mailto:slotosch@...

http://www.validas.de

fon: +49 (0) 89 / 53 88 669-11

fax: +49 (0) 89 / 53 88 669-10

--

Validas AG

Firmensitz: Arnulfstr. 27, D-80335 München

Registergericht: Amtsgericht München HRB 131653

Vorstand: Dr. Oscar Slotosch, Dr. Peter Braun

Aufsichtsratsvorsitzender: Prof. Dr. Dr. h.c. Manfred Broy

 


Re: Process assessment on the Linux kernel development process

Oscar Slotosch
 

Hi Nicole,

you have a different job now, so I am happy to continue the discussion with you.

 

I think we are working towards the same goal, it’s just that you are starting from the item and I am starting from the ISO 26262 & IEC 61508

Standard (which I know better than Linux right now, even if I had a first look to the kernel code).

So hopefully we will meet in the middle: you starting from the Linux process and we from the standards.

 

My plan is to define a safety compliant (and model-based) process that includes development and qualification of Linux

and show that both together is compliant to safety standard, i.e. I would like to answer the questions of programming guidelines positive.

 

I invite you on 4th 16:00 December (all) to Munich at Validas to join a presentation of a “Safety Plan for Linux Qualification” that I will present

In a nice advent atmosphere. There I will also make a proposal how to be compliant with programming guidelines and would be happy to get your feedback.

 

I will send around a separate invitation (and we plan to record the talk on video for you).

 

Kind regards and a nice weekend,

                Oscar

--

Enjoy our new podcast: Tool and Library Qualification at http://www.validas.de/en/podcast/

--

Validas AG

Dr. Oscar Slotosch

Vorstand

mailto:slotosch@...

http://www.validas.de

fon: +49 (0) 89 / 53 88 669-11

fax: +49 (0) 89 / 53 88 669-10

--

Validas AG

Firmensitz: Arnulfstr. 27, D-80335 München

Registergericht: Amtsgericht München HRB 131653

Vorstand: Dr. Oscar Slotosch, Dr. Peter Braun

Aufsichtsratsvorsitzender: Prof. Dr. Dr. h.c. Manfred Broy

 

--

Enjoy our new podcast: Tool and Library Qualification at http://www.validas.de/en/podcast/

--

Validas AG

Dr. Oscar Slotosch

Vorstand

mailto:slotosch@...

http://www.validas.de

fon: +49 (0) 89 / 53 88 669-11

fax: +49 (0) 89 / 53 88 669-10

--

Validas AG

Firmensitz: Arnulfstr. 27, D-80335 München

Registergericht: Amtsgericht München HRB 131653

Vorstand: Dr. Oscar Slotosch, Dr. Peter Braun

Aufsichtsratsvorsitzender: Prof. Dr. Dr. h.c. Manfred Broy

 

Von: Nicole Pappler [mailto:Nicole@...]
Gesendet: Freitag, 15. November 2019 08:32
An: Oscar Slotosch
Cc: Nicole Pappler; devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi Oscar,

just wondering what made you think I would not be around anymore?

I don't understand your current issue with the coding guidelines. In an assessment you always have to consider the use case and characteristics, environment etc of the item/process you'd like to assess. And in some of the assessments that will require an assessor to know (or be willing to learn) about stuff that did not come up in standard assessments up to now. I know I sound like some broken vinyl record - but blind standard compliance will not result automatically in a safe system. 

So with respect to the kernel I suggest that we initially try to figure out what is already there and how it is applied in everyday kernel mainline, and sort it to the clauses that typically come up in our safety standards.Then we really have to consider if the formal requirement from the standard would be beneficial in the kernel mainline process and if there is already something there that fulfills this. Or figuring out if there are other measures in place and analyzing if there are other, in the context of the kernel more useful measures in place. Or if we need to think about other measures that might become of value that we could suggest to the kernel developers or the kernel users.

What I'd really like to suggest here, is take a step-by-step analytical approach regarding the kernel process. Not with the focus on getting easy compliance argumentation, but with the goal to figure out the current strength, possible gaps and for sure also to get a deeper understanding what would really add (safety) value here. 

Maybe we should discuss this in our call today, I'm quite curious if there is anybody in favor of this idea vs. finding a compliance argument, but I am sorry, I am not sure if I can make it to the call, I might be stuck in a train without reception.

Best regards,

Nicole

 

 

 

Am 2019-11-14 07:45, schrieb Oscar Slotosch:

Hello Nicole,

happy to have you still with us and thank you for the pointer to the linux guidelines.

 

But it makes a difference in having guidelines and having compliant guidelines.

For Example: In the table I send there is written "usage of language subsets" and when you read in the link you pointed me (Programming Language),

You find the following sentence: "This dialect contains many extensions to the language [gnu-extensions], and many of them are used within the kernel as a matter of course."

 

So how do you plan to convince an assessor that this "extension" is a "language subset"?

 

Kind regards,

            Oscar

PS

Those are the points that come to my mind when making a "compliance argumentation" for the requirements that will pass any assessor (as usually our compliance argumentations do;-)

 

 

 

Von: devel@... [mailto:devel@...] Im Auftrag von Nicole Pappler
Gesendet: Donnerstag, 14.
November 2019 07:25
An: Priyanka Viswanathan
Cc:
ElisaMainList@...; Lukas Bulwahn; devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

actually reusing stuff from SIL2Linux MP sounds great - I also can remember we discussed some stuff in the Workshop at Mentor about 2 or 3 years ago. 

As my viewpoint naturally is more on the gap-seeking and not at the problem resolution side, how about Priyanka, Lukas and whoever is also interested in contributing set up something to start assessing. And in a next step I can have a look on it, how it would fit into a rough safety-assessment model? Maybe together with somebody else from the assessor side here in the mailinglist? To get a view that is not so automotive centric?

 

@Oscar: regarding coding guidelines etc you should find your answer at: https://www.kernel.org/doc/html/latest/process/index.html

 

BR,

Nicole

 

 

Am 2019-11-13 16:49, schrieb Priyanka Viswanathan:

Hi Nicole and Lukas,

 

I was discussing the aspects of doing the process assessment of the Kernel Development Process with Jochen after our presentation at Lyon.

Based on my background/experience I think I will also be able to contribute to this and have some ideas but would like to discuss this in our weekly meeting this week.

 

I also heard that some similar work had been done in SIL2Linux MP, it would be get an overview of the approach used and any results so that we can use any lessons learnt.

 

Kind Regards,
Priyanka

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: 13 November 2019 15:13
To: Lukas Bulwahn <Lukas.Bulwahn@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

 


Re: Process assessment on the Linux kernel development process

Lukas Bulwahn
 

Dear all,

 

The work from Wolfgang Mauerer, Ralf Ramsauer (OTH Regensburg), Sebastian Duda (master student at FAU Erlangen, mentored here at BMW) and me which I did as a small "free-time" project was presented at the Embedded Linux Conference Europe 2019 in Lyon, and the LWN.net author Jake Edge has written a nice article on this work:

 

https://lwn.net/Articles/804511/

 

(If you cannot access this link above, you should consider to ask your company to get a LWN.net subscription. It is worth it.)

 

I hope that this can motivate this group to investigate/provide evidences on qualities of the Linux kernel development process and this shows how this can be done in a simple example.

 

 

Best regards,

 

 

Von: devel@... [mailto:devel@...] Im Auftrag von Lukas Bulwahn
Gesendet: Mittwoch, 13. November 2019 20:19
An: joyabrata.ghosh@...; ElisaMainList@...
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

 

The presentation is about some initial attempts of trying to do process assessments based on data mining techniques. I am sure available on the mailing list and in the weekly call for detailed questions of the approach; source code is available under GPL-2.0.

 

Best regards,

 

Lukas

 

Von: Joyabrata.Ghosh@... [mailto:Joyabrata.Ghosh@...]
Gesendet: Mittwoch, 13. November 2019 16:40
An: ElisaMainList@...; Bulwahn Lukas, JC-20 <Lukas.Bulwahn@...>
Cc: devel@...
Betreff: RE: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

 

just added the link, which Nicole referenced inline:

 

link:   https://osseu19.sched.com/event/TPGw/the-list-is-our-process-an-analysis-of-the-kernels-email-based-development-process-ralf-ramsauer-oth-regensburg-sebastian-duda-bmw-ag

slide: Pasta Elce19

 

Devel call: does it make sense ? what are pros and cons ?

 

 

Best Regards

Joy

Software Engineer A

CoC Integrated Software Solutions

 

EB - Driving the future of Software

Branch München, Frankfurter Ring 117, 80807 München
Mobile: +49 177 966 7070

Phone:  +49 9131 7701 6348
joyabrata.ghosh@...
https://www.automotive.elektrobit.com

PGP-Key: https://securemail.elektrobit.com/web.app

 

Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Deutschland
Managing Directors: Alexander Kocher, Gregor Zink

Chairman Supervisory Board: Karlheinz Haupt
Register Court Fürth HRB 4886

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler
Sent: Wednesday, November 13, 2019 4:13 PM
To: Bulwahn, Lukas (Bmw) <Lukas.Bulwahn@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 


Re: Process assessment on the Linux kernel development process

Lukas Bulwahn
 

Hi Jochen,

 

Part of Thorsten’s engagement probably gave quite some insights in the regard of categories you mentioned below; I do not know if he actually started creating a statistics on that, though.

 

If we organize as a group of three-four people, create some standard templates as responses to some standard user reports, split up the activity of following, recording the category and answering to the user or forwarding actual valid reports, we can probably quickly have a proper quantitative assessment of the situation and we can propose practical implementable tasks to improve regression tracking.

 

Again Thorsten’s work and activity could serve as great starting point.

 

Best regards,

 

Lukas

 

Von: devel@... [mailto:devel@...] Im Auftrag von Jochen Kall
Gesendet: Freitag, 15. November 2019 12:45
An: Bulwahn Lukas, JC-20 <Lukas.Bulwahn@...>; Muhammad.Adeel@...; ElisaMainList@...; Priyanka.Viswanathan@...
Cc: devel@...; linux@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi Lukas,

 

all I meant to express is that it seems to happen that good and relevant bug reports do not to get enough attention because of the volume of less helpful ones.

 

After some reflection, probably too harsh a statement indeed, also a bit misleading maybe, sorry about that.

Especially since i’m not sure how correct it actually is.

 

I hear this complaint about bad bug reports a lot though, and that makes me wonder if we can quantify the problem and replace anecdotical knowledge with some facts.

 

Do the bugtrackers have statistics on why a bug-report is rejected/closed?

Categories like the ones you mentioned:

  • Not relevant to mainline development
  • Misunderstanding on reporter side
  • Not a bug report in the first place
  • Actual „Nonsense“ like the report Lars showed us in Cambridge with someone complaining his selfconstructed keyboard doesnt work.

 

There are quarterly reports from the Kernel Bugzilla

https://wiki.documentfoundation.org/File:QA-Stats.ods

where the situation does not look that dire actually.

Also statistics can be visualized directly as plots here :

https://bugzilla.kernel.org/query.cgi?format=report-graph

however the fine granular information why bug reports get rejected does not seem to be availlable.

 

Best regards

Jochen

 

Von: Lukas.Bulwahn@... <Lukas.Bulwahn@...>
Gesendet: Freitag, 15. November 2019 10:20
An: Jochen Kall <Jochen.Kall@...>; Muhammad.Adeel@...; ElisaMainList@...; Priyanka.Viswanathan@...
Cc: devel@...; linux@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear Jochen, dear Muhammed, dear all,

 

 

Jochen, that sentence is a bit harsh on both sides, the reporters and the assignees:

 

“The bugtrackers are being drowned in nonsense”

 

Some of the reports are simply not relevant to the mainline development, some are user misunderstandings, some are questions from new developers, but not a real regression or bug. And some are real bugs and then somebody could be taking care of them.

 

Some people answer on bugzilla, others simply request to contact the relevant mailing lists (and some people take care of it on the mailing list).

 

Certainly there might be issues in this area and we would like to have them resolved or mitigate against that weakness. Thorsten Leemhuis has looked into this topic and reported on it in 2017:

 

https://lwn.net/Articles/737666/

https://lwn.net/Articles/738216/

 

I had multiple attempts to get Thorsten to present his personal conclusion of his regression tracking efforts in 2017 within our working group; and I have not given up yet. Possibly, he is willing to give us an hour of his time as a small Christmas present (when business cools down at the end of the year and he has a bit more time than usual).

 

If there are more people interested in this topic, please let us all know here (including everyone in CC). A cheering crowd for Thorsten here might motivate him.

 

 

Best regards,

 

Lukas

 

Von: devel@... [mailto:devel@...] Im Auftrag von Jochen Kall
Gesendet: Donnerstag, 14. November 2019 10:09
An: Adeel, Muhammad <Muhammad.Adeel@...>; ElisaMainList@...; Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi Muhammed,

 

bug tracking is one of the major systematic problems still open, that need to be adressed to get the kernel fit for safety applications.

The main problem is, that dealing with all the bug reports is just not feasible at the moment, due to the sheer volume of them, many of which are not meaningful in the first place.

In a nutshell, the bugtrackers are being drowned in nonsense, and there is not enough manpower to sift through all of that, also its not that fun appearently.

A solution for that, would be highly welcome, if you have Ideas, we are listening ^^

 

Best regards,

Jochen

 

Von: devel@... <devel@...> Im Auftrag von Adeel, Muhammad
Gesendet: Donnerstag, 14. November 2019 09:54
An: ElisaMainList@...; Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi,

 

When I read the title of this post, I asked a question to myself - Does Kernel have a development process?  I think Kernel development process is patches here and there which are most of the time irrelevant to you. But, the thing which is important for you, are the bugs and they are not tracked.

 

Let me give you an example, I posted a bug to netdev mailing list few days ago asking even for the name of the maintainer of Unix Domain Socket. But, I think the community doesn't know it and nobody cares. Here are the details: https://lore.kernel.org/netdev/CABT=TjEWnpD3oJCJXUUN9P+gGM+k1iS84LXdebfOTOCM+vHeCA@.../T/#t

 

I am sure this bug will also be ignored as many others for UDS reported by different people over many years. Only syzkaller reports 100's of them each month, but do we know are they resolved or even looked upon? There is no bug tracking, no Jira tickets etc.

 

Sorry I should introduce myself as this is my first post to the forum. My name is Muhammad Adeel and I work for AOX. I found ELISA on Linux Foundation page and I find it useful so I joined this group. I would be more than happy if I could contribute to it.

 

Thanks and Regards,

Adeel

 

Muhammad Adeel

Senior Embedded Software Engineer

AOX Technologies GmbH

office:

+49 (7721) 4061 3381

muhammad.adeel@...

Karlsruher Straße 21, 78048 Villingen‑Schwenningen

https://www.aox-tech.de

AOX Technologies GmbH
​Geschäftsführung: Rainer Oder

​Handelsregister: Amtsgericht Freiburg i.Br., HRB 718402
​Sitz der Gesellschaft: Karlsruher Straße 21, 78048 Villingen‑Schwenningen
​USt‑Id Nummer: DE319460217 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. [0v01-aoxtech-full]

Von: devel@... <devel@...> Im Auftrag von Nicole Pappler via Lists.Elisa.Tech
Gesendet: Donnerstag, 14. November 2019 07:25
An: Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

actually reusing stuff from SIL2Linux MP sounds great - I also can remember we discussed some stuff in the Workshop at Mentor about 2 or 3 years ago. 

As my viewpoint naturally is more on the gap-seeking and not at the problem resolution side, how about Priyanka, Lukas and whoever is also interested in contributing set up something to start assessing. And in a next step I can have a look on it, how it would fit into a rough safety-assessment model? Maybe together with somebody else from the assessor side here in the mailinglist? To get a view that is not so automotive centric?

 

@Oscar: regarding coding guidelines etc you should find your answer at: https://www.kernel.org/doc/html/latest/process/index.html

 

BR,

Nicole

 

 

Am 2019-11-13 16:49, schrieb Priyanka Viswanathan:

Hi Nicole and Lukas,

 

I was discussing the aspects of doing the process assessment of the Kernel Development Process with Jochen after our presentation at Lyon.

Based on my background/experience I think I will also be able to contribute to this and have some ideas but would like to discuss this in our weekly meeting this week.

 

I also heard that some similar work had been done in SIL2Linux MP, it would be get an overview of the approach used and any results so that we can use any lessons learnt.

 

Kind Regards,
Priyanka

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: 13 November 2019 15:13
To: Lukas Bulwahn <
Lukas.Bulwahn@...>
Cc:
devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


--

Mit freundlichen Grüßen
Jochen Kall

 

--
Dr. rer. nat. Jochen Kall

Funktionale Sicherheit

 

ITK Engineering GmbH
Im Speyerer Tal 6
76761 Rülzheim

 

Tel.: +49 7272 7703-546
Fax: +49 7272 7703-100

Mobil:+491734957776

 

mailto:jochen.kall@...

 

______________________________________________________________

 

ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim

Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100

mailto:info@... | http://www.itk-engineering.de

 

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:

Dr. Rudolf Maier

Geschäftsführung/Executive Board:

Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke

Sitz der Gesellschaft/Registered Office: 76761 Rülzheim

Registergericht/Registered Court: Amtsgericht Landau, HRB 32046

USt.-ID-Nr./VAT-ID-No. DE 813165046


--

Mit freundlichen Grüßen
Jochen Kall

 

--
Dr. rer. nat. Jochen Kall

Funktionale Sicherheit

 

ITK Engineering GmbH
Im Speyerer Tal 6
76761 Rülzheim

 

Tel.: +49 7272 7703-546
Fax: +49 7272 7703-100

Mobil:+491734957776

 

mailto:jochen.kall@...

 

______________________________________________________________

 

ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim

Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100

mailto:info@... | http://www.itk-engineering.de

 

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:

Dr. Rudolf Maier

Geschäftsführung/Executive Board:

Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke

Sitz der Gesellschaft/Registered Office: 76761 Rülzheim

Registergericht/Registered Court: Amtsgericht Landau, HRB 32046

USt.-ID-Nr./VAT-ID-No. DE 813165046


Re: Process assessment on the Linux kernel development process

Smith, Jason
 

Hi Nicole,

 

I fully support your perspective.  I think it is well-aligned with the goals of ELISA.

 

Compliance/certification is not to be ignored, but if all Linux was concerned with was compliance/certification, they could have not bothered with forming ELISA and instead hired a consultant to create a bunch of beautiful paperwork in support of a compliance argument.  I’m sure then that *someone* would have been willing to certify it, whether or not it was right or wrong, or actually made things safer.  Hate to say it, but I know this has happened before.

 

That being said, standards are some of the best resources to figure out how to make things safer, as long as the intent of their requirements are met and not lost in context.  Requirements from functional safety standards serve as the basis for the document I drafted, for example.

 

Anyway, just wanted to support you and say that I believe the step-by-step/gap analysis approach that you suggested seems like the best approach for now, and will allow us to solve one problem at a time.

 

J

 

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: Friday, November 15, 2019 1:32 AM
To: Oscar Slotosch <slotosch@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi Oscar,

just wondering what made you think I would not be around anymore?

I don't understand your current issue with the coding guidelines. In an assessment you always have to consider the use case and characteristics, environment etc of the item/process you'd like to assess. And in some of the assessments that will require an assessor to know (or be willing to learn) about stuff that did not come up in standard assessments up to now. I know I sound like some broken vinyl record - but blind standard compliance will not result automatically in a safe system. 

So with respect to the kernel I suggest that we initially try to figure out what is already there and how it is applied in everyday kernel mainline, and sort it to the clauses that typically come up in our safety standards.Then we really have to consider if the formal requirement from the standard would be beneficial in the kernel mainline process and if there is already something there that fulfills this. Or figuring out if there are other measures in place and analyzing if there are other, in the context of the kernel more useful measures in place. Or if we need to think about other measures that might become of value that we could suggest to the kernel developers or the kernel users.

What I'd really like to suggest here, is take a step-by-step analytical approach regarding the kernel process. Not with the focus on getting easy compliance argumentation, but with the goal to figure out the current strength, possible gaps and for sure also to get a deeper understanding what would really add (safety) value here. 

Maybe we should discuss this in our call today, I'm quite curious if there is anybody in favor of this idea vs. finding a compliance argument, but I am sorry, I am not sure if I can make it to the call, I might be stuck in a train without reception.

Best regards,

Nicole

 

 

 

Am 2019-11-14 07:45, schrieb Oscar Slotosch:

Hello Nicole,

happy to have you still with us and thank you for the pointer to the linux guidelines.

 

But it makes a difference in having guidelines and having compliant guidelines.

For Example: In the table I send there is written "usage of language subsets" and when you read in the link you pointed me (Programming Language),

You find the following sentence: "This dialect contains many extensions to the language [gnu-extensions], and many of them are used within the kernel as a matter of course."

 

So how do you plan to convince an assessor that this "extension" is a "language subset"?

 

Kind regards,

            Oscar

PS

Those are the points that come to my mind when making a "compliance argumentation" for the requirements that will pass any assessor (as usually our compliance argumentations do;-)

 

 

 

Von: devel@... [mailto:devel@...] Im Auftrag von Nicole Pappler
Gesendet: Donnerstag, 14. November 2019 07:25
An: Priyanka Viswanathan
Cc: ElisaMainList@...; Lukas Bulwahn; devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

actually reusing stuff from SIL2Linux MP sounds great - I also can remember we discussed some stuff in the Workshop at Mentor about 2 or 3 years ago. 

As my viewpoint naturally is more on the gap-seeking and not at the problem resolution side, how about Priyanka, Lukas and whoever is also interested in contributing set up something to start assessing. And in a next step I can have a look on it, how it would fit into a rough safety-assessment model? Maybe together with somebody else from the assessor side here in the mailinglist? To get a view that is not so automotive centric?

 

@Oscar: regarding coding guidelines etc you should find your answer at: https://www.kernel.org/doc/html/latest/process/index.html

 

BR,

Nicole

 

 

Am 2019-11-13 16:49, schrieb Priyanka Viswanathan:

Hi Nicole and Lukas,

 

I was discussing the aspects of doing the process assessment of the Kernel Development Process with Jochen after our presentation at Lyon.

Based on my background/experience I think I will also be able to contribute to this and have some ideas but would like to discuss this in our weekly meeting this week.

 

I also heard that some similar work had been done in SIL2Linux MP, it would be get an overview of the approach used and any results so that we can use any lessons learnt.

 

Kind Regards,
Priyanka

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: 13 November 2019 15:13
To: Lukas Bulwahn <Lukas.Bulwahn@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

 


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.


Re: Process assessment on the Linux kernel development process

Lukas Bulwahn
 

Von: devel@... [mailto:devel@...] Im Auftrag von
Thomas Gleixner
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux
kernel development process
On Fri, 15 Nov 2019, Lukas Bulwahn wrote:

Some of the reports are simply not relevant to the mainline
development, some are user misunderstandings, some are questions from
new developers, but not a real regression or bug. And some are real
bugs and then somebody could be taking care of them.

Some people answer on bugzilla, others simply request to contact the
relevant mailing lists (and some people take care of it on the mailing
list).

Certainly there might be issues in this area and we would like to have
them resolved or mitigate against that weakness. Thorsten Leemhuis has
looked into this topic and reported on it in 2017:

https://lwn.net/Articles/737666/
https://lwn.net/Articles/738216/

I had multiple attempts to get Thorsten to present his personal
conclusion of his regression tracking efforts in 2017 within our
working group; and I have not given up yet. Possibly, he is willing to
give us an hour of his time as a small Christmas present (when
business cools down at the end of the year and he has a bit more time than
usual).

It's a tedious and not necessarily rewarding work which is just too big to
handle for a volunteer with limited time.

The main problem is, that nobody really feels responsible to put man-power
on it or to provide the funding for people who are willing to do this. If that
can be solved, then I'm sure that the right people with the required skills can
be found.
I strongly agree. If there is a company/a set of companies that has high interest in delivering a high-quality Linux kernel in their product, they probably are well aware of potential issues and known bugs well before they ship the kernel to the public (in an continuous field operation).

Among various measures, the Bugzilla bug tracker might be useful for that purpose, but it requires companies to actually fund a group with the required skills to take care of that.


Lukas


Re: Presentation on AGL and ELISA collaboration: AGL base for Instrument Cluster & IVI telltales safety function

Lukas Bulwahn
 

Dear Naoto-san,

At ELISA, we are all happy to help and use the "Linux kernel for the AGL instrument cluster" as an object of investigation and the telltales safety function as use case for discussion.

To do so, we need a bit more information to get started. So, I would like to immediately kick off the discussion here with the following questions:

- Following AGL's mantra "Code First", where can we find the repository in which you define the Linux kernel for the AGL instrument cluster?

A pointer to the bitbake recipe in a AGL git repository would be great. Then, we can build the Linux kernel for the AGL instrument cluster for our investigation purpose. If you have not decided for a different kernel than the AGL unified base or have not created a separate config for the AGL instrument cluster, a confirmation that using the IVI kernel and the IVI config from AGL is a good way to continue the investigation for now would be great. Also, it would be good to know if and when you plan to provide a dedicated kernel and kernel config for the instrument cluster.

- To your slide "Case study : Telltale", I would like to know a bit more details:

- What is the safety requirement of the telltale functionality exactly?
- What is the "fail-safe" state of the overall system?
- How is this safety requirement assumed to be broken down to the different components?

I can see different ways of breaking down the requirements, some break-downs require less requirements on the overall systems, other break-downs might require availability requirements of some system elements, which are really difficult to achieve.

I am happy to assist in structuring the description of the use case to allow the group in ELISA to understand the requirements towards the Linux kernel.

Thanks for helping us to get together and figuring out how ELISA can contribute to your working group.


Best regards,

Lukas


Re: Process assessment on the Linux kernel development process

Jochen Kall
 

Hi Lukas,

 

all I meant to express is that it seems to happen that good and relevant bug reports do not to get enough attention because of the volume of less helpful ones.

 

After some reflection, probably too harsh a statement indeed, also a bit misleading maybe, sorry about that.

Especially since i’m not sure how correct it actually is.

 

I hear this complaint about bad bug reports a lot though, and that makes me wonder if we can quantify the problem and replace anecdotical knowledge with some facts.

 

Do the bugtrackers have statistics on why a bug-report is rejected/closed?

Categories like the ones you mentioned:

  • Not relevant to mainline development
  • Misunderstanding on reporter side
  • Not a bug report in the first place
  • Actual „Nonsense“ like the report Lars showed us in Cambridge with someone complaining his selfconstructed keyboard doesnt work.

 

There are quarterly reports from the Kernel Bugzilla

https://wiki.documentfoundation.org/File:QA-Stats.ods

where the situation does not look that dire actually.

Also statistics can be visualized directly as plots here :

https://bugzilla.kernel.org/query.cgi?format=report-graph

however the fine granular information why bug reports get rejected does not seem to be availlable.

 

Best regards

Jochen

 

Von: Lukas.Bulwahn@... <Lukas.Bulwahn@...>
Gesendet: Freitag, 15. November 2019 10:20
An: Jochen Kall <Jochen.Kall@...>; Muhammad.Adeel@...; ElisaMainList@...; Priyanka.Viswanathan@...
Cc: devel@...; linux@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear Jochen, dear Muhammed, dear all,

 

 

Jochen, that sentence is a bit harsh on both sides, the reporters and the assignees:

 

“The bugtrackers are being drowned in nonsense”

 

Some of the reports are simply not relevant to the mainline development, some are user misunderstandings, some are questions from new developers, but not a real regression or bug. And some are real bugs and then somebody could be taking care of them.

 

Some people answer on bugzilla, others simply request to contact the relevant mailing lists (and some people take care of it on the mailing list).

 

Certainly there might be issues in this area and we would like to have them resolved or mitigate against that weakness. Thorsten Leemhuis has looked into this topic and reported on it in 2017:

 

https://lwn.net/Articles/737666/

https://lwn.net/Articles/738216/

 

I had multiple attempts to get Thorsten to present his personal conclusion of his regression tracking efforts in 2017 within our working group; and I have not given up yet. Possibly, he is willing to give us an hour of his time as a small Christmas present (when business cools down at the end of the year and he has a bit more time than usual).

 

If there are more people interested in this topic, please let us all know here (including everyone in CC). A cheering crowd for Thorsten here might motivate him.

 

 

Best regards,

 

Lukas

 

Von: devel@... [mailto:devel@...] Im Auftrag von Jochen Kall
Gesendet: Donnerstag, 14. November 2019 10:09
An: Adeel, Muhammad <Muhammad.Adeel@...>; ElisaMainList@...; Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi Muhammed,

 

bug tracking is one of the major systematic problems still open, that need to be adressed to get the kernel fit for safety applications.

The main problem is, that dealing with all the bug reports is just not feasible at the moment, due to the sheer volume of them, many of which are not meaningful in the first place.

In a nutshell, the bugtrackers are being drowned in nonsense, and there is not enough manpower to sift through all of that, also its not that fun appearently.

A solution for that, would be highly welcome, if you have Ideas, we are listening ^^

 

Best regards,

Jochen

 

Von: devel@... <devel@...> Im Auftrag von Adeel, Muhammad
Gesendet: Donnerstag, 14. November 2019 09:54
An: ElisaMainList@...; Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi,

 

When I read the title of this post, I asked a question to myself - Does Kernel have a development process?  I think Kernel development process is patches here and there which are most of the time irrelevant to you. But, the thing which is important for you, are the bugs and they are not tracked.

 

Let me give you an example, I posted a bug to netdev mailing list few days ago asking even for the name of the maintainer of Unix Domain Socket. But, I think the community doesn't know it and nobody cares. Here are the details: https://lore.kernel.org/netdev/CABT=TjEWnpD3oJCJXUUN9P+gGM+k1iS84LXdebfOTOCM+vHeCA@.../T/#t

 

I am sure this bug will also be ignored as many others for UDS reported by different people over many years. Only syzkaller reports 100's of them each month, but do we know are they resolved or even looked upon? There is no bug tracking, no Jira tickets etc.

 

Sorry I should introduce myself as this is my first post to the forum. My name is Muhammad Adeel and I work for AOX. I found ELISA on Linux Foundation page and I find it useful so I joined this group. I would be more than happy if I could contribute to it.

 

Thanks and Regards,

Adeel

 

Muhammad Adeel

Senior Embedded Software Engineer

AOX Technologies GmbH

office:

+49 (7721) 4061 3381

muhammad.adeel@...

Karlsruher Straße 21, 78048 Villingen‑Schwenningen

https://www.aox-tech.de

AOX Technologies GmbH
​Geschäftsführung: Rainer Oder

​Handelsregister: Amtsgericht Freiburg i.Br., HRB 718402
​Sitz der Gesellschaft: Karlsruher Straße 21, 78048 Villingen‑Schwenningen
​USt‑Id Nummer: DE319460217 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. [0v01-aoxtech-full]

Von: devel@... <devel@...> Im Auftrag von Nicole Pappler via Lists.Elisa.Tech
Gesendet: Donnerstag, 14. November 2019 07:25
An: Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

actually reusing stuff from SIL2Linux MP sounds great - I also can remember we discussed some stuff in the Workshop at Mentor about 2 or 3 years ago. 

As my viewpoint naturally is more on the gap-seeking and not at the problem resolution side, how about Priyanka, Lukas and whoever is also interested in contributing set up something to start assessing. And in a next step I can have a look on it, how it would fit into a rough safety-assessment model? Maybe together with somebody else from the assessor side here in the mailinglist? To get a view that is not so automotive centric?

 

@Oscar: regarding coding guidelines etc you should find your answer at: https://www.kernel.org/doc/html/latest/process/index.html

 

BR,

Nicole

 

 

Am 2019-11-13 16:49, schrieb Priyanka Viswanathan:

Hi Nicole and Lukas,

 

I was discussing the aspects of doing the process assessment of the Kernel Development Process with Jochen after our presentation at Lyon.

Based on my background/experience I think I will also be able to contribute to this and have some ideas but would like to discuss this in our weekly meeting this week.

 

I also heard that some similar work had been done in SIL2Linux MP, it would be get an overview of the approach used and any results so that we can use any lessons learnt.

 

Kind Regards,
Priyanka

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: 13 November 2019 15:13
To: Lukas Bulwahn <
Lukas.Bulwahn@...>
Cc:
devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


--

Mit freundlichen Grüßen
Jochen Kall

 

--
Dr. rer. nat. Jochen Kall

Funktionale Sicherheit

 

ITK Engineering GmbH
Im Speyerer Tal 6
76761 Rülzheim

 

Tel.: +49 7272 7703-546
Fax: +49 7272 7703-100

Mobil:+491734957776

 

mailto:jochen.kall@...

 

______________________________________________________________

 

ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim

Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100

mailto:info@... | http://www.itk-engineering.de

 

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:

Dr. Rudolf Maier

Geschäftsführung/Executive Board:

Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke

Sitz der Gesellschaft/Registered Office: 76761 Rülzheim

Registergericht/Registered Court: Amtsgericht Landau, HRB 32046

USt.-ID-Nr./VAT-ID-No. DE 813165046


--

Mit freundlichen Grüßen
Jochen Kall

 

--
Dr. rer. nat. Jochen Kall

Funktionale Sicherheit

 

ITK Engineering GmbH
Im Speyerer Tal 6
76761 Rülzheim

 

Tel.: +49 7272 7703-546
Fax: +49 7272 7703-100

Mobil:+491734957776

 

mailto:jochen.kall@...

 

______________________________________________________________

 

ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim

Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100

mailto:info@... | http://www.itk-engineering.de

 

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:

Dr. Rudolf Maier

Geschäftsführung/Executive Board:

Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke

Sitz der Gesellschaft/Registered Office: 76761 Rülzheim

Registergericht/Registered Court: Amtsgericht Landau, HRB 32046

USt.-ID-Nr./VAT-ID-No. DE 813165046


Re: Process assessment on the Linux kernel development process

Thomas Gleixner
 

Lukas,

On Fri, 15 Nov 2019, Lukas Bulwahn wrote:

Some of the reports are simply not relevant to the mainline development,
some are user misunderstandings, some are questions from new developers,
but not a real regression or bug. And some are real bugs and then
somebody could be taking care of them.

Some people answer on bugzilla, others simply request to contact the
relevant mailing lists (and some people take care of it on the mailing
list).

Certainly there might be issues in this area and we would like to have
them resolved or mitigate against that weakness. Thorsten Leemhuis has
looked into this topic and reported on it in 2017:

https://lwn.net/Articles/737666/
https://lwn.net/Articles/738216/

I had multiple attempts to get Thorsten to present his personal
conclusion of his regression tracking efforts in 2017 within our working
group; and I have not given up yet. Possibly, he is willing to give us an
hour of his time as a small Christmas present (when business cools down at
the end of the year and he has a bit more time than usual).
It's a tedious and not necessarily rewarding work which is just too big to
handle for a volunteer with limited time.

The main problem is, that nobody really feels responsible to put man-power
on it or to provide the funding for people who are willing to do this. If
that can be solved, then I'm sure that the right people with the required
skills can be found.

Thanks,

Thomas


Re: [SUSPECTED SPAM] Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

Wild, Doris
 

Dear all,

 

I would like to contribute to this topic as well.

 

Unfortunately, I don’t bring Linux development experience with me, but I can contribute by comparing the steps demanded by the Kernel development community for development/bugfixing the kernel with the activities/methods required by ISO 26262 and IEC 61508.

 

Kind regards,

Doris

 

 

 

Von: devel@... [mailto:devel@...] Im Auftrag von Nicole Pappler
Gesendet: Mittwoch, 13. November 2019 16:13
An: Lukas Bulwahn <Lukas.Bulwahn@...>
Cc: devel@...
Betreff: [SUSPECTED SPAM] Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 


Re: Process assessment on the Linux kernel development process

Lukas Bulwahn
 

Dear Jochen, dear Muhammed, dear all,

 

 

Jochen, that sentence is a bit harsh on both sides, the reporters and the assignees:

 

“The bugtrackers are being drowned in nonsense”

 

Some of the reports are simply not relevant to the mainline development, some are user misunderstandings, some are questions from new developers, but not a real regression or bug. And some are real bugs and then somebody could be taking care of them.

 

Some people answer on bugzilla, others simply request to contact the relevant mailing lists (and some people take care of it on the mailing list).

 

Certainly there might be issues in this area and we would like to have them resolved or mitigate against that weakness. Thorsten Leemhuis has looked into this topic and reported on it in 2017:

 

https://lwn.net/Articles/737666/

https://lwn.net/Articles/738216/

 

I had multiple attempts to get Thorsten to present his personal conclusion of his regression tracking efforts in 2017 within our working group; and I have not given up yet. Possibly, he is willing to give us an hour of his time as a small Christmas present (when business cools down at the end of the year and he has a bit more time than usual).

 

If there are more people interested in this topic, please let us all know here (including everyone in CC). A cheering crowd for Thorsten here might motivate him.

 

 

Best regards,

 

Lukas

 

Von: devel@... [mailto:devel@...] Im Auftrag von Jochen Kall
Gesendet: Donnerstag, 14. November 2019 10:09
An: Adeel, Muhammad <Muhammad.Adeel@...>; ElisaMainList@...; Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi Muhammed,

 

bug tracking is one of the major systematic problems still open, that need to be adressed to get the kernel fit for safety applications.

The main problem is, that dealing with all the bug reports is just not feasible at the moment, due to the sheer volume of them, many of which are not meaningful in the first place.

In a nutshell, the bugtrackers are being drowned in nonsense, and there is not enough manpower to sift through all of that, also its not that fun appearently.

A solution for that, would be highly welcome, if you have Ideas, we are listening ^^

 

Best regards,

Jochen

 

Von: devel@... <devel@...> Im Auftrag von Adeel, Muhammad
Gesendet: Donnerstag, 14. November 2019 09:54
An: ElisaMainList@...; Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi,

 

When I read the title of this post, I asked a question to myself - Does Kernel have a development process?  I think Kernel development process is patches here and there which are most of the time irrelevant to you. But, the thing which is important for you, are the bugs and they are not tracked.

 

Let me give you an example, I posted a bug to netdev mailing list few days ago asking even for the name of the maintainer of Unix Domain Socket. But, I think the community doesn't know it and nobody cares. Here are the details: https://lore.kernel.org/netdev/CABT=TjEWnpD3oJCJXUUN9P+gGM+k1iS84LXdebfOTOCM+vHeCA@.../T/#t

 

I am sure this bug will also be ignored as many others for UDS reported by different people over many years. Only syzkaller reports 100's of them each month, but do we know are they resolved or even looked upon? There is no bug tracking, no Jira tickets etc.

 

Sorry I should introduce myself as this is my first post to the forum. My name is Muhammad Adeel and I work for AOX. I found ELISA on Linux Foundation page and I find it useful so I joined this group. I would be more than happy if I could contribute to it.

 

Thanks and Regards,

Adeel

 

Muhammad Adeel

Senior Embedded Software Engineer

AOX Technologies GmbH

office:

+49 (7721) 4061 3381

muhammad.adeel@...

Karlsruher Straße 21, 78048 Villingen‑Schwenningen

https://www.aox-tech.de

AOX Technologies GmbH
​Geschäftsführung: Rainer Oder

​Handelsregister: Amtsgericht Freiburg i.Br., HRB 718402
​Sitz der Gesellschaft: Karlsruher Straße 21, 78048 Villingen‑Schwenningen
​USt‑Id Nummer: DE319460217 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. [0v01-aoxtech-full]

Von: devel@... <devel@...> Im Auftrag von Nicole Pappler via Lists.Elisa.Tech
Gesendet: Donnerstag, 14. November 2019 07:25
An: Priyanka Viswanathan <Priyanka.Viswanathan@...>
Cc: devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

actually reusing stuff from SIL2Linux MP sounds great - I also can remember we discussed some stuff in the Workshop at Mentor about 2 or 3 years ago. 

As my viewpoint naturally is more on the gap-seeking and not at the problem resolution side, how about Priyanka, Lukas and whoever is also interested in contributing set up something to start assessing. And in a next step I can have a look on it, how it would fit into a rough safety-assessment model? Maybe together with somebody else from the assessor side here in the mailinglist? To get a view that is not so automotive centric?

 

@Oscar: regarding coding guidelines etc you should find your answer at: https://www.kernel.org/doc/html/latest/process/index.html

 

BR,

Nicole

 

 

Am 2019-11-13 16:49, schrieb Priyanka Viswanathan:

Hi Nicole and Lukas,

 

I was discussing the aspects of doing the process assessment of the Kernel Development Process with Jochen after our presentation at Lyon.

Based on my background/experience I think I will also be able to contribute to this and have some ideas but would like to discuss this in our weekly meeting this week.

 

I also heard that some similar work had been done in SIL2Linux MP, it would be get an overview of the approach used and any results so that we can use any lessons learnt.

 

Kind Regards,
Priyanka

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: 13 November 2019 15:13
To: Lukas Bulwahn <Lukas.Bulwahn@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


--

Mit freundlichen Grüßen
Jochen Kall

 

--
Dr. rer. nat. Jochen Kall

Funktionale Sicherheit

 

ITK Engineering GmbH
Im Speyerer Tal 6
76761 Rülzheim

 

Tel.: +49 7272 7703-546
Fax: +49 7272 7703-100

Mobil:+491734957776

 

mailto:jochen.kall@...

 

______________________________________________________________

 

ITK Engineering GmbH | Im Speyerer Tal 6 | 76761 Rülzheim

Tel.: +49 7272 7703-0 | Fax: +49 7272 7703-100

mailto:info@... | http://www.itk-engineering.de

 

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board:

Dr. Rudolf Maier

Geschäftsführung/Executive Board:

Michael Englert (Vorsitzender/Chairman), Bernd Gohlicke

Sitz der Gesellschaft/Registered Office: 76761 Rülzheim

Registergericht/Registered Court: Amtsgericht Landau, HRB 32046

USt.-ID-Nr./VAT-ID-No. DE 813165046


Re: Process assessment on the Linux kernel development process

Nicole Pappler
 

Hi Oscar,

just wondering what made you think I would not be around anymore?

I don't understand your current issue with the coding guidelines. In an assessment you always have to consider the use case and characteristics, environment etc of the item/process you'd like to assess. And in some of the assessments that will require an assessor to know (or be willing to learn) about stuff that did not come up in standard assessments up to now. I know I sound like some broken vinyl record - but blind standard compliance will not result automatically in a safe system. 

So with respect to the kernel I suggest that we initially try to figure out what is already there and how it is applied in everyday kernel mainline, and sort it to the clauses that typically come up in our safety standards.Then we really have to consider if the formal requirement from the standard would be beneficial in the kernel mainline process and if there is already something there that fulfills this. Or figuring out if there are other measures in place and analyzing if there are other, in the context of the kernel more useful measures in place. Or if we need to think about other measures that might become of value that we could suggest to the kernel developers or the kernel users.

What I'd really like to suggest here, is take a step-by-step analytical approach regarding the kernel process. Not with the focus on getting easy compliance argumentation, but with the goal to figure out the current strength, possible gaps and for sure also to get a deeper understanding what would really add (safety) value here. 

Maybe we should discuss this in our call today, I'm quite curious if there is anybody in favor of this idea vs. finding a compliance argument, but I am sorry, I am not sure if I can make it to the call, I might be stuck in a train without reception.

Best regards,

Nicole

 

 

 

Am 2019-11-14 07:45, schrieb Oscar Slotosch:

Hello Nicole,

happy to have you still with us and thank you for the pointer to the linux guidelines.

 

But it makes a difference in having guidelines and having compliant guidelines.

For Example: In the table I send there is written "usage of language subsets" and when you read in the link you pointed me (Programming Language),

You find the following sentence: "This dialect contains many extensions to the language [gnu-extensions], and many of them are used within the kernel as a matter of course."

 

So how do you plan to convince an assessor that this "extension" is a "language subset"?

 

Kind regards,

            Oscar

PS

Those are the points that come to my mind when making a "compliance argumentation" for the requirements that will pass any assessor (as usually our compliance argumentations do;-)

 

 

 

Von: devel@... [mailto:devel@...] Im Auftrag von Nicole Pappler
Gesendet: Donnerstag, 14. November 2019 07:25
An: Priyanka Viswanathan
Cc: ElisaMainList@...; Lukas Bulwahn; devel@...
Betreff: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

actually reusing stuff from SIL2Linux MP sounds great - I also can remember we discussed some stuff in the Workshop at Mentor about 2 or 3 years ago. 

As my viewpoint naturally is more on the gap-seeking and not at the problem resolution side, how about Priyanka, Lukas and whoever is also interested in contributing set up something to start assessing. And in a next step I can have a look on it, how it would fit into a rough safety-assessment model? Maybe together with somebody else from the assessor side here in the mailinglist? To get a view that is not so automotive centric?

 

@Oscar: regarding coding guidelines etc you should find your answer at: https://www.kernel.org/doc/html/latest/process/index.html

 

BR,

Nicole

 

 

Am 2019-11-13 16:49, schrieb Priyanka Viswanathan:

Hi Nicole and Lukas,

 

I was discussing the aspects of doing the process assessment of the Kernel Development Process with Jochen after our presentation at Lyon.

Based on my background/experience I think I will also be able to contribute to this and have some ideas but would like to discuss this in our weekly meeting this week.

 

I also heard that some similar work had been done in SIL2Linux MP, it would be get an overview of the approach used and any results so that we can use any lessons learnt.

 

Kind Regards,
Priyanka

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: 13 November 2019 15:13
To: Lukas Bulwahn <
Lukas.Bulwahn@...>
Cc:
devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

 


Re: Process assessment on the Linux kernel development process

Ted Strandberg
 

Hi Nicole,

I think it is a good initiative to resume work towards a certification. When it comes to assessing and reviewing the safety documentation, I am happy to contribute (from the assessor side) at the stage when there is sufficiently good documentation to review.
If the task is to analyze the Linux kernel development process used today and generate documents, I'm afraid that my knowledge in this area is too weak and I guess other persons in the group are better suited.

 

While looking at the documentation, I think it is important to look at the technical solutions that would be possible to apply in order to achieve the goals with a certification, otherwise there is a risk that the documentation is a waste of work.

BR / Ted

 

 

Från: devel@... <devel@...> För Nicole Pappler via Lists.Elisa.Tech
Skickat: den 14 november 2019 07:25
Till: Priyanka Viswanathan <Priyanka.Viswanathan@...>
Kopia: devel@...
Ämne: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Hi all,

actually reusing stuff from SIL2Linux MP sounds great - I also can remember we discussed some stuff in the Workshop at Mentor about 2 or 3 years ago. 

As my viewpoint naturally is more on the gap-seeking and not at the problem resolution side, how about Priyanka, Lukas and whoever is also interested in contributing set up something to start assessing. And in a next step I can have a look on it, how it would fit into a rough safety-assessment model? Maybe together with somebody else from the assessor side here in the mailinglist? To get a view that is not so automotive centric?

 

@Oscar: regarding coding guidelines etc you should find your answer at: https://www.kernel.org/doc/html/latest/process/index.html

 

BR,

Nicole

 

 

Am 2019-11-13 16:49, schrieb Priyanka Viswanathan:

Hi Nicole and Lukas,

 

I was discussing the aspects of doing the process assessment of the Kernel Development Process with Jochen after our presentation at Lyon.

Based on my background/experience I think I will also be able to contribute to this and have some ideas but would like to discuss this in our weekly meeting this week.

 

I also heard that some similar work had been done in SIL2Linux MP, it would be get an overview of the approach used and any results so that we can use any lessons learnt.

 

Kind Regards,
Priyanka

 

 

From: devel@... <devel@...> On Behalf Of Nicole Pappler via Lists.Elisa.Tech
Sent: 13 November 2019 15:13
To: Lukas Bulwahn <Lukas.Bulwahn@...>
Cc: devel@...
Subject: Re: [ELISA Technical Community] Process assessment on the Linux kernel development process

 

Dear all,

sorry I did not make it to the call last Friday.

Doing a process assessment sounds good, I think with my background I could contribute to this. Does anybody have an idea already who we should bring together to get all the required information? I could maybe work offline with the stuff I can find at kernel.org, but for sure it might make more sense to do this in a bigger setup.

@Lukas: Can we maybe also re-use some of the stuff regarding the mailing-list-requirements-process that BMW master student (sorry, forgot the name) presented in Lyon?

Best regards,

Nicole

 

 

 

Am 2019-11-11 08:53, schrieb Lukas Bulwahn:

Dear all,
 
on the weekly meeting last Friday, some people mentioned deeper interest in doing a process assessment on the Linux kernel development process.
 
If we would like to move this forward, we should coordinate on this topic:
 
Who has an initial idea how to structure such an process assessment?
Who has some first investigation and assessment to share?
Who would like to contribute to those activities?
 
 
Best regards,
 
Lukas
 
 
 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.