Hi Lukas,

I thought I'd let the fourth fall before I leave. This is the last conceptual part and it's not too long. Maybe the dust will have settled by the time I've returned.

The world is not so clear-cut. The developers are also users. But... not all users are developers.

It should be clear that at least some of the developers contributing code to Linux work for companies that develop Linux-based systems. All probably develop on Linux-based systems. Some users are pure users and just use the code in their systems and don't contribute to the Linux Kernel. Some developers may work on deep, general issues

In the group's discussion about whether the upper group should be called downstream developers or users, I would tend to using the term users. It may be a tired, ambiguous, oft-used term, but it describes what I see with a brutal clarity: by my definition, the users are users because they use the software (i.e. without modification), nothing more.

What you have proposed[1] is a model and from a process perspective, "users" and "development community" are roles. The terms are a little confusing as I think of users as being individuals, not organisations. Of course, the same person can be both a user and a Linux developer.


From your original e-mail:

However, the Linux kernel community also offers the following interface for the suggested development procedures for any User:

a release candidate is published, Linus asks: ... "Go out and test...

Who is he addressing here? Isn't it the Linux Development Community, not a user per your definition?

the Linux Kernel Development Community reacts to that feedback, and clear regressions (usually)
lead to fixes or removal of the complete functionality causing the regression.

Again the Development Community is involved... and the result is source code. But, as with patches that make it to staging, the development community generates some activity on the mailing lists that reflect design or architectural decisions.

The first impression I had was that the development community just contributed the to the main deliverable, the source code repository. I see a class of user-developers that conceive enhancements / modifications / new features for the kernel. There would then be 3 roles in the process: the pure developers which submit code to the repository, the user-developers which may or may not contribute code but who also contribute enhancements with architecture / design implications and users, who as the name says, just use Linux, as in select and configure the available code.

For this e-mail, I've enhanced the safety-critical lifecycle diagramme with 3 corresponding communities (enclosed). The line of demarcation between the "pure" development community and the user-development community is somewhat arbitrary. As a first guess, I've put it above module design. The upper group might be called "user community", but I think that if they were indeed a community, they band together and get involved in the development. Per definition, that is not what I intend.

In the next e-mail, I'll discuss the implications of this perspective on the work in the group and ELISA's position in the community.

[1] https://docs.google.com/document/d/1d91Znr2IWPI3pgDk_Nz2BcVNWHQgyBxk_18dAqnskiw/edit?usp=sharing

Mit freundlichen Grüßen / Best regards

John MacGregor

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

-----Original Message-----
From: development-process@... <development-
process@...> On Behalf Of Lukas Bulwahn
Sent: Montag, 27. April 2020 15:20
To: development-process@...
Subject: [development-process] "Pseudo-DIA" between the Linux Kernel
Development Community and its Users

Dear all,

(sorry, this has been way too long in my email draft folder... but it is also quite a
lengthy email)


Elana, Jochen et al. has proposed a good structure to document the existing
development process. This will help us to document our understanding, spread
information among each other and determine the criticality of certain
gaps/weaknesses in the development process. Then, we have a common plan what
we would like to increase our shared efforts on address in the future wrt.
development process in the Linux kernel development community.

As I said, while doing my part of the work (release planning), I hit an issue when
defining release planning/releasing. I have observed the same, or at least similar,
issue in the work of other topics as well, e.g., in management aspects, and impact
analysis for new releases.

I simply was not sure if there is a common agreement/understanding on what we
(each individual and we as common group) think "the Linux Kernel Development
Community delivers" (what is the output of what the Linux Kernel Development
Community) and "what the Linux Kernel Development Community requests from its
Users" (how do they agree on that historically, how do you need to behave based on
that agreement; what you would need to provide as input) and "what the Users need
to do because they need to do it for their product development".

So, I quickly tried to define the Linux Kernel Development Community and the User
as terms in the glossary, but that only a very partial solution to the issue I faced.

Linux Kernel Development Community: The Linux Kernel Development Community
is an organizational entity that encompasses all persons that have contributed
(directly or indirectly) to changes to the Linux Kernel.
The main deliverable from the Linux Kernel Development Community is the Linux
kernel source code repository (the tree in the git repository and its history),
containing a pre-existing configurable software.

User: The User is an (abstract) organizational entity that develops a system, which
includes one specific configuration of the pre-existing configurable software (Linux
Kernel), and puts this system into the public space. The term User may incorporate
multiple organizations in a supply chain up to the OEM, and it includes all phases of
the system development, from system design, requirements engineering,
configuring the kernel, building the kernel, HW-SW integration and to production,
maintenance and decommission.

The definitions above are an extract from the Glossary at
https://docs.google.com/document/d/1d91Znr2IWPI3pgDk_Nz2BcVNWHQgyBxk_1
8dAqnskiw/edit?usp=sharing.

For a better solution based on those definitions, I came up with this basic idea:

# Why describe the scope of Linux Kernel Development Community and its
interface?

The motivation to describe the scope of Linux Kernel Development Community and
its interface more precisely is:

1. initially, for us to improve our common understanding: When we talk about
considering the execution of a process step (in the standards' understanding), do we
mean: do we assume to the process step is executed by the Users or by the
Community? What are expectations that come with that activity?

2. later, for anyone else trying to understand the basic assumptions what the user
explicitly needs to do and what the user needs to check to hold (control they still
hold) about what we state at a certain point in time about the development process
(and which might not hold at a later point in time).

3. later, to motivate stakeholders to support certain procedural changes in the Linux
kernel community (or actually, community suborganizations that are relevant to the
stakeholders) or to engage in the community to implement this change.

# How to describe the scope of Linux Kernel Development Community and its
interface?

To describe the scope of Linux Kernel Development Community and its interface, I
propose to formulate a "pseudo DIA" (I would certainly like to find a better suitable
term than that, and I am happy to hear any quickly brain-stormed suggestions in this
mail thread).

First, we introduce the standards' definition of a development interface agreement
(DIA), summarizing the expectation of and then explain the relevant difference of a
"pseudo DIA" for an open-source development to a traditional (customer-supplier)
DIA.

According to ISO 26262, Edition 2, Part 1, 3.32, a Development Interface
Agreement (DIA) is an "agreement between customer and supplier in which the
responsibilities for activities to be performed, evidence to be reviewed, or work
products (3.185) to be exchanged by each party related to the development of items
(3.84) or elements (3.41) are specified."

This definition includes the following characteristics:
a. a specification of the scope, i.e., the development of an item or element
b. an agreement between two parties involved in the development of that scope
c. description of activities
d. assignment of activities to each party
e. acceptance of the responsibility on that activity by the assigned party
f. description of resulting evidences or work products that need to be created by
one party and provided as input to the other party for a further activity.

# Understanding the default agreement between the Kernel Community and its
Users

When we consider a software delivery/release of the Linux kernel, the Linux Kernel
Development Community makes the following offer to all its Users.
Concerning the legally binding offer, the GPL License clearly states (in capital
letters):

NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS
NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM
"AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO
IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO
MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED
ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL,
SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF
THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE
PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH
HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.

(quoting Clause 11 & 12 of the GPL 2.0 License, https://www.gnu.org/licenses/old-
licenses/gpl-2.0.en.html)

So, in short, the Linux kernel does what it does (there is no fitness for a particular
purpose), comes with no claim of quality of any kind, and all risks are in the users
sole responsibility.

However, the Linux kernel community also offers the following interface for the
suggested development procedures for any User:

First, whenever a release candidate is published, Linus asks:

"Go out and test (and special thanks to people who already did, and started sending
reports even during the merge window)" (Linus Torvalds, Linux 5.5-rc1,
https://lwn.net/Articles/806771/) "So peeps - go build it, install it and boot it, and
report back any problems you see," (Linus Torvalds, Linux 5.5-rc2,
https://lwn.net/Articles/807349/) "but please do use the down-time to do some extra
testing instead, ok?" (Linus Torvalds, Linux 5.5-rc3, https://lwn.net/Articles/808000/,
shortly before Christmas break) "Scan the shortlog below if you are into that, but
otherwise just go forth and test it out all," (Linus Torvalds, Linux 5.5-rc6,
https://lwn.net/Articles/809255/) " Please do test, there should be nothing scary going
on." (Linus Torvalds, Linux 5.5-rc7, https://lwn.net/Articles/810011/)

It is probably an interesting of study of English literature to create a full list of quotes
where Linus asks on various ways over and over for the one thing that he requests
from the Users, namely to test the provided release candidate and report any issues.
Then when the User sends back a report of a bug or regression, the Linux Kernel
Development Community reacts to that feedback, and clear regressions (usually)
lead to fixes or removal of the complete functionality causing the regression.

And with the final release, Linus asks as well:

"Anyway. Go out and test 5.5" (Linus Torvalds, Linux 5.5,
https://lwn.net/Articles/810579/)

But at this point, there is a consensus that the majority of the community has moved
on, and the reports back on this version later are handled differently. Ultimately, it is
up to the user to test during the release candidates and report back to the
community, and nevertheless to test the final release on fitness for the user's
purpose. For most users---although they may be unaware of it---, this agreement is
sufficient to build products relying on these provided Linux kernel releases.

# Useful Interpretation of a DIA for the Linux kernel for specific environments

Specific environments, such as systems under certain regulations, critical
environments, i.e., high-integrity, safety- or security-related systems, may intend or
require a clear and formalized understanding of which activities of an assumed
overall system and software development process, the kernel community is
executing and which activities are to be executed by the user.
This description is often needed to estimate the risks of the kernel development
process and to reduce those risks by further mitigating activities by the user.

A "Pseudo-DIA" includes the following characteristics:
a. a specification of the scope, i.e., the development of an item or element
b. a definition of two parties involved in the development of that scope
c. description of activities
d. assignment of activities to each party,
e. evidences that the assignment meets the actual reality of executed activities
among the two parties
f. description of resulting evidences or work products that need to be created by
one party and provided as input to the other party for a further activity.

In other words, a "Pseudo-DIA" can describe "a specific scenario between two
parties in which activities are performed, evidences are reviewed, or work products
(3.185) are exchanged between two parties related to the development of items
(3.84) or elements (3.41) are specified."

# Difference between DIA and Pseudo-DIA

Compared to an DIA, the definition of a Pseudo-DIA differs in the following aspects:

An agreement between two parties involved in the development of that scope (DIA,
b.) is replaced by a definition of two parties involved in the development of that
scope (Pseudo-DIA, b.).

Acceptance of the responsibility on that activity by the assigned party (DIA, e.) is
replaced by evidences that the assignment meets the actual reality of executed
activities among the two parties (Pseudo-DIA, e.).

The difference is inherently due to the structure of the organization around an open-
source project, and the common agreement among developers and users to
exclude warranty of any kind, as far as legally permitted.

Hence, a Pseudo-DIA does not represent a signed agreement between two
organizations. There is no one from the community as a representative that can sign
this agreement, as a community comes to conclusion by merit-based consensus,
not by strict enforcement from single individuals towards other peers within an
organization (e.g., in a hierarchical structured organization, with enforced roles and
capabilities to enforce behavior of others). Further, the individuals would not really
sign such an agreement towards specific users without further contractual
agreements, as there is no incentive to the signer in his role as representative of the
community.

Note, in different roles and within different organizational structure, somebody might
sign such agreement with another organization, but then it more likely to be in a
setting similar to traditional customer-supplier relationships.

As a Pseudo-DIA only includes a definition, but not an agreement, the author of a
Pseudo-DIA does not need to be affiliated in any way to any of the two parties that
are described in the Pseudo-DIA.

# Value of a Pseudo-DIA

The value of such a pseudo-DIA is determined by the degree that the provided
definition reflects the actual reality of the activities among the two parties, or is at
least attractive and realistically achievable as envisioned development process to
the two parties, which we will call Community and User in the following description.

The activity of creating or following a Pseudo-DIA, i.e., determining an assignment
of activities/aspects to those two parties, the User can understand how the quality
assurance/assessment of each specific activity could generally be used for an
overall development process assessment:

1. in case you assign an activity to the User, the Pseudo-DIA author's
recommendation is that the User needs to execute the whole activity within its
organization.

2. in case you assign it to the Community, the Pseudo-DIA author's
recommendation is that the User needs to observe if the Community actually
executes the activity and determine if the activity is done with sufficient care and
rigor for the User's interest.
(The development-process group might provide methods and tools to allow efficient
observation of Community behavior.)

So, in any case, it is ALWAYS the User that needs to do something, but the activity
is slightly different in the two cases.

Despite the difference to an DIA, an appropriate Pseudo-DIA can achieve a similar
confidence of truth (or trust) in a development process assignment as a DIA. The
agreement on a Pseudo-DIA, missing formally in the Pseudo-DIA artefact,
consequently happens by an implicit consistent behavior of the two parties to the
provided definition and by confident monitoring of the activities and relevant qualities
of those activities with suitable and effective reactions in case the behavior of any of
the two parties change. All information gathered while monitoring the activities and
qualities can serve as evidence towards any third party.

# Example content for the Pseudo-DIA Description

To conclude the definition of a Pseudo-DIA, we describe one example of Pseudo-
DIA activity descriptions and assignment for the Linux kernel.

Example: Management of Competence

ISO 26262, Part 2, Clause 5.4.4.1 states: The organization shall ensure that the
persons involved in the execution of the safety lifecycle have a sufficient level of
skills, competence and qualification corresponding to their responsibilities.

In the further example, the aspects are defined as follows:

a. a specification of the scope, i.e., the development of an item or element:
The scope of this Pseudo-DIA is the Linux kernel v5.5, ultimately integrated in
Linus Torvalds git repository and tagged as v5.5 by Linus Torvalds during the release
process of v5.5. This definition in this example excludes the later v5.5.y versions in
the linux-stable repository.

b. a definition of two parties involved in the development of that scope:
The Linux Kernel Community and the User as defined above.

c. description of the activities:
Basically, we assume the Linux Kernel Development Community is responsible
for design, implementation and documentation of the functionality implemented in
v5.5; that the requirements fit to the use case, testing, verification and validation is to
the user. Hence, for this main responsibility, the sufficient level of skills, competence
and qualification is knowledge of the C dialect used for kernel development and
experience and knowledge in operating system design and implementation.
Ensuring that each person has sufficient level is split into the following activities:
identification of competence for each contributor, clear documentation of the
contributor's role within the development community and the contributions,
determination if competence fits to contributor's role according to criticality of the
functionality to the product safety.

d. assignment of activities to each party:
The activities above are assigned as follows:
Identification of competence for each contributor is assigned to the Linux Kernel
Development Community.
Clear documentation of the contributor's role within the development community
and the contributions is assigned to the Linux Kernel Development Community.
Determination if competence fits to contributor's role according to criticality of the
functionality to the product safety is assigned to the User.

e. evidences that the assignment meets the actual reality of executed activities
among the two parties:
The contributor's competence can be judged based on the previous contributions
to the Linux kernel repository and their involvement in email review. All contributions
by an individual are recorded and significant contributions of suggestions and review
are recorded with further tags in the commit message. Continuous unhelpful review
is eventually marked by the Linux kernel community by ignorance of those
contributions. The role of central developers are recorded and maintained in the
MAINTAINERS file.
The User has to check that the community continues to archive all contributions and
email discussion and to maintain MAINTAINERS appropriately.

f. description of resulting evidences or work products that need to be created by
one party and provided as input to the other party for a further activity.
The Linux Kernel Development Community provides a clear list of all contributors
and their contributions, i.e., git history and email archives. The User needs to check
availability of all recent information of all relevant sources. The User needs to make
the judgement if the contributor had sufficient competence for the relevance of the
contribution and mitigate with further activities if the competence if not considered
sufficient. The User is responsible for mitigations of identified shortcomings with
regard to competence management for the specific product usage. Note, at the
moment, the gap from a practical view could to be that the current interface
between Linux Kernel Development Community and the User is a "rather raw-data
interface"; the User has not yet defined an interface that might be more suitable for
the product-relevant competence judgement than the currently described interface.

# Afterword

To be clear, this is NOT thought as replacement of the current plan and activity in
the development process group, but as (possibly later) an addition---depending on
the relevance of the Community-User interface for the topic of your investigation,
which I hit quickly for release planning during the definition already. So, I will focus
on describing release planning first, get that done and then assist wherever I can on
the current tasks and then see how to progress with this work here. So far, here is
only one example, I had further ones in mind but then I decided to get this email out
first, and come up with further descriptions of example when needed.

Nevertheless, please comment and provide feedback. Especially, I would like to
know if it helpful for you or not now or if we shall delay determining a consensus to a
later point.

After I got some initial feedback on the mailing list, I will transfer the consensus of
this discussion then into a first draft of a Google Doc (you can probably already see
a first document structure in this email) and we can then work together on the
details.



Best regards,

Lukas