Analyse of CR "Tiered SW Platform (Operating System) Integration"

[PandaeDo]

Participants:

• @aschemmel-tech
• @PandaeDo

Scope:
We want to check if the CR is applicable from process perspective. The CR is described here:
#1740

Important for the understanding is also this chapter in the initial description.
#1691 (comment)

#1691 was the starting point and was then transferred into a CR #1740.

Meeting Minutes:

We had a look on the definition of S-CORE https://eclipse.dev/score/. With this starting point we try to analyse what potential impacts there might be. Therefore we use the information's from the new PR for SW-Platform AoU eclipse-score/process_description#197.

Also we had a look on https://eclipse-score.github.io/score/main/modules/os/docs/index.html. The OS is already described as a component. On stakeholder level we have two non functional requirements. Functional requirements are missing.

The information which configurations are possible can be gained trough the links.

Open questions:

• Is the description Meta Feature Request: Platform request #1691 (comment) to be discussed? The requirement that OS Vendor has to guarantee e.g. 2 experts seems a little bit unrealistic
• It's not clear who is responsible for the tasks. For example the minimal requirements for Tier-2 we guess it's a mix between S-CORE and OS responsibilities. That has to be clarified
• Shall it also be possible to downgrade a OS? This should be described
• It's not clear how we should show that components matches with Tier-2 / Tier-3 requirements. Therefore we might need another type

Decisions:

• We want to use the expressions on the picture https://eclipse.dev/score/ so that a SW Platform contains Middleware, OS, ....

Solution approach:

• We need a decision from architectural perspective how we want to implement the tiered SW platform
• We prefer to have an approach based on components
• We need process adaptions that we can see which component match to which OS
• Description of way of tiered OS integration shall be described by volunteers
• Update of process descriptions will be done by Process Community

Next Steps:

Follow up:
Next meeting is planned for 8. October at 15 o'clock.

Topics:
Finalize the analysis to present the results to Process Development Community

[qor-lb]

Thank you very much for the review! Here a quick feedback to the questions that you have posted:

Is the description #1691 (comment) to be discussed? The requirement that OS Vendor has to guarantee e.g. 2 experts seems a little bit unrealistic

Yes this is only the first draft, this has to be further refined as we move along. The requirement is not intended to limit that these people necessarily need to be employed by the OS vendor. The goal is rather that we do have access to two individuals that are familiar with the OS and can support in case there are any questions during the integration or during a potential bug found in the integration test. The idea to extend this to two individuals starting Tier-2 was to give S-CORE the confidence to have access to specialists if we want to provide further guarantees for the OS. (Avoid the issue that 1 person is on vacation for 6 weeks and therefore we can no longer ensure operability of this target).

It's not clear who is responsible for the tasks. For example the minimal requirements for Tier-2 we guess it's a mix between S-CORE and OS responsibilities. That has to be clarified

Yes correct, we need to make this more explicit in the description. The idea was that there are always 2 parts per tier:

1. A guarantee given by the S-CORE project once the target is promoted to a tier.
   Example: For tier 2 we want to guarantee the functional correctness of S-CORE on this specific target. This means that for every integration/release (see DR-002-Infra: Integration Testing in a Distributed Monolith) S-CORE has the responsibility to ensure that tests actually execute on this target and and that the change does not break these guarantees.
2. A set of entry requirements that have to be provided by the promoter so that the tier can be promoted
   Example: For tier 2 these are the elements that are listed in minimal requirements

Shall it also be possible to downgrade a OS? This should be described

I think we should definitely have this! We only need to align on the criteria, when this can be initiated and who has to approve this.

It's not clear how we should show that components matches with Tier-2 / Tier-3 requirements. Therefore we might need another type

I would see the OS not as part of the S-CORE platform but part of the environment. I.e. S-CORE does not include the OS but S-CORE operates on top of a OS. If we have this view we can say that the Tiers define guarantees for (all components of) S-CORE to operate on/be compatible with a specific OS & Architecture.

IMO I would therefore not favor to treat the OS as a component itself.

[PandaeDo]

Participants:

• @aschemmel-tech
• @PandaeDo

Scope:
Continue on yesterdays discussion

Meeting Minutes:
We discussed the the answers from @qor-lb. They are very helpful! Starting with the remark not to treat the OS as a component itself we discussed the two options (include OS as component and exclude it) again. There are a lot of advantages and disadvantages for both solutions.

We considered:

• Audit remark that we'll need a architectural view with OS integrated for certification
• Location of the documentation
• Responsibilities for Requirements and Tests
• Visibility of the OS can be needed to draw a full picture of an OS
• Documentation of component over index.rst and possible adoption to module by adoption
• Creation of a hybrid approach to have a collection of general needed functions as a integrated component and all specific solutions outside

Decisions:

• CR shall be updated to have also the perspective of authors on the discussed topics
• Creation of PR to have a solution to proof if all aspects are covered

Next Steps:

• Presentation tomorrow in Process Development Community