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 - 2/5 We're talking about an Operating System here
Agree. If we exclude the run-time code, there is no "coding" (as in changing C code) involved.
However, you would expect this complete process above to be executed under some quality management (and the execution of those activities meeting some procedural requirements).
So, it is relevant to formulate the requirements that we would expect to be met for those steps in the context of "selecting and configuring a Linux kernel".
There are then OS-related aspects to the validation activities whichI agree that the system developer has the task (and the responsibility) to select, configure and test the operating system.
I do not agree to the statement that "no development is involved".
You describe above a complete development step, and I believe multiple clauses in the standards apply; although, it never results in code.
It only results in a kernel build configuration, and this kernel build configuration is the interface to the operating system supplier.
The system developer wants that the operating system supplier provides "a good implementation" for this kernel build configuration.
That is the implicit DIA here. Then the operating system supplier executes an own "development process" down to the implementation (with his own V model process).
And longer question:
So, does the operating system supplier or the system developer test the operating system?
(I have an assumption here and there is again a certain split of the activities in this area.)
I think a process description should cover these insights above from you, and the assumed responsibilities here.
(If this is part of a DIA or some even more basic overview document on the process is secondary to me; we will figure it out while constructing.)
It is clear though (even if we do not have the description) that we certainly need to have the common understanding, e.g., as you described the overall process above, and one core aspect of it is "who does what". Otherwise, this mapping of ISO clauses/QM standards (ASPICE and such) to described activities is hardly to understand.
As we see in this discussion, already on the higher levels, we assume multiple "V-model like development process" happening in some interweaved and temporally decoupled way.
Documenting that as if it is "one V-model process" will probably distort the whole process assessment and that has impact on results (at least, in comprehensibility, and maybe even in the risk assessment).
Agree. I consider this a completely new and different development process, that needs a DIA in itself.
An organization making a DIA with itself is the default. Usually, the organization using Linux will act internally and as part of the community. That does not invalidate the idea of a DIA. Still activities in the community are different than the activities that are done internally, and in the end, the quality statement comes from understanding how well both activities (internally, and in the community with others) work, and how well they "work together" (interact, are aligned, etc.).
While a system developer must choose an operating system from the flavoursAgree. That is the upfront development to the development process above.
Summarizing, we identified three "development processes":
1. Understanding the system needs and selecting and configuring the operating system appropriately. Result: kernel build configuration
2. Previous development process of the operating system (without any involvement of the own organization)
Result: source code (relevant here to the system integrator is the source code for kernel build configuration above)
3. Specific development process of the operating system (with involvement of the own organization and a clear goal towards a specific quality level)
Result: New features specifically driven by extensions of 1.
Again, 2. And 3. Intersect but it help in the discussion to separate those.
Do you agree to "all" above?
I let it sink on the mailing list and then see where such basic information must be documented for this process assessment we are executing to be comprehensible. Maybe it is just a scope section, as it is already a split of activities on a very high level, not on individual clauses.