This group is locked. No changes can be made to the group while it is locked.
Re: "Pseudo-DIA" between the Linux Kernel Development Community and its Users - 1/5 Introductory response
John MacGregor <john.macgregor@...>
Hi Lukas,toggle quoted message Show quoted text
My response has now been sitting around in my draft folder for half an eternity as well. For me, your email is pretty wide-ranging t's taken a while to sift the things out.
Basically I really like the idea of having a "Pseudo-DIA", a documented description of the division of labour and responsibilities between a system developer and the Linux open source community in developing a safety-critical system. While a real DIA is a forms a documented legal agreement between a customer and a supplier about the split of development activities, content and quality of the deliverables, roles and responsibilities, it is clear that in our case the system developer can only document the corresponding expectations and is responsible for filling in any gaps that arise.
This is where I initially hit a dead-end. Basically you asked whether the Pseudo-DIA was a good idea and the answer was "yes". But, the "yes" was just a "yes" on principles. There are a number of issues about the practice that should be clarified. Some of your descriptions seemed to indicate that we agree, but I couldn't be sure.
Taking the term literally, in the "Development Interface Agreement", I wasn't sure which "development" you were referring to or what the "Interface" would be. For me, different OEMs, or any system developer for that matter, can have a number of types of arrangement with their suppliers: from turn-key subsystems through joint development to development to spec. The different arrangements imply different interfaces between supplier and customer with each taking different roles and responsibilities in the different development phases. I wasn't even sure we have the same understanding of what the Linux development process does or does not do.
Using competence management as an example wasn't very illuminating. Of course, competence management is an issue, but for me the development interface should primarily define who does which parts of the development process and with which responsibility.
I'm going to start with a couple of observations and see where that leads us. Rather than trying to shoehorn everything into one omnibus e-mail, I've decided to make separate e-mails for a number of issues. Note that they reflect the world as I see it. I expect that others will see it differently.
Have fun reading.
Mit freundlichen Grüßen / Best regards
Safety, Security and Privacy (CR/AEX4)
Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY | www.bosch.com
Tel. +49 711 811-42995 | Mobil +49 151 543 09433 | John.MacGregor@...
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian Fischer, Dr. Stefan Hartung,
Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke, Peter Tyroller