DR-001-Arch: Consistent Stack vs. Reference Integration#2560
DR-001-Arch: Consistent Stack vs. Reference Integration#2560
Conversation
qor-lb
requested review from
PandaeDo,
aschemmel-tech,
masc2023 and
pahmann
as code owners
|
|
|
The created documentation from the pull request is available at: docu-html |
qor-lb
requested review from
FScholPer,
antonkri and
johannes-esr
as code owners
|
Seems related to #2346, Feature as stand-alone Delivery? |
Yes agree, added it to the list in the description above. |
FScholPer
left a comment
FScholPer
left a comment
There was a problem hiding this comment.
What option is accepted or did I miss something?
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
see inline comment
FScholPer
left a comment
FScholPer
left a comment
There was a problem hiding this comment.
no accepted option defined
@FScholPer the decision is right after the context: https://github.com/eclipse-score/score/pull/2560/changes#diff-7605e72a4577a9aeeadf15aca38407709dc0eff885ee5684e8d46097ef932da8R44 |
There was a problem hiding this comment.
Original (blocking) remark is covered. As I understood the discussion in "Alignment Tech Leads, Community Leads & Feature Team Leads" meeting, there needs to be some description how we want to deal with "breaking API changes", which would also differentiate between "small" and "big" changes. Maybe a possibility to differentiate is to ask: "is this change affecting the logical interface described in our Feature Architecture?" - because if yes, the process is asking for a "Feature Change Request" which would also result in planning activities.
|
|
||
| In particular, the consistent stack approach does not prevent modules or features from being independently buildable or releasable, nor from being used outside the S-CORE stack. | ||
|
|
||
| The decision only establishes that, when modules are integrated into S-CORE, their evolution and changes must be justified in terms of stack-level objectives. |
There was a problem hiding this comment.
Imho the heart of the question is about responsibility for breaking changes and that goes beyond "changes must be justified in terms of stack-level objectives".
Let's assume module X makes a breaking change from version 42 to 43 and an S-CORE release is imminent. Now I see two options how integration can be handled and they somewhat correspond to the considered options 1 and 2:
Option 1: Module X does not integrate, thus we cannot release S-CORE yet. Integrators organize to get the version 43 improvements in.
Option 2: Module X does not integrate, thus we release S-CORE with old version 42. Module X if you want to be in the release, you need to work.
There was a problem hiding this comment.
@a-zw from my perspective both options would still be valid even under the current proposed decision. I have added a subsection to the Impact on Governance and Planning section to try and clarify that. Let me know it this resolves your comment or if you feel differently.
There was a problem hiding this comment.
Ok, I understand that this question is out of scope for this DR.
Now I wonder what is actually in scope? The central implication seems to be "Changes, especially breaking changes, must be justified in terms of stack-level requirements."
That feels like a weak wish. What happens if a module introduces a breaking change unjustified (intentionally or unintentionally)?
There was a problem hiding this comment.
@a-zw the point of this DR is a step before enforcement: it's about establishing consensus what we want.
Before we can discuss how to handle unjustified breaking changes procedurally, or how to detect them with tooling, we need to agree on whether we want justification at all. The alternative is that S-CORE simply has to adapt during integration, and modules carry no obligation to the stack.
That's the question this DR intends answers: no, we don't just "deal with it", modules that are part of the stack are expected to justify breaking changes against stack-level requirements.
Everything you're asking about (what happens if they don't, how we enforce it, how automation can help) is exactly the set of follow-up discussions this DR is meant to enable. Those belong in subsequent DRs, because they only make sense once we've agreed on the principle.
So I would push back slightly on "weak wish", it's an intentionally declarative statement. The teeth should come later, and that is by design.
|
@aschemmel-tech @FScholPer are your concerns addressed? If yes, could you please approve so that we can move the PR forward? |
can you just write the option which was Choosen or set the status to progress. Then we can just optimize the text in a next PR |
|
@FScholPer this is the decision (see diff or html):
IMO merging this as "in progress" has the same effect as keeping this PR open. We should target to reach consensus soon so that we can baseline further DRs on this. |
|
|
||
| This option increases coordination and change management overhead during development. In return, it establishes a clear architectural contract. Changes are evaluated based on their impact on the stack, and the reference stack is expected to remain usable. | ||
|
|
||
| ## Consequences |
There was a problem hiding this comment.
Please add Option 3:
-
Goal for RefInt:
- To show that all S-CORE modules can be (continuously) integrated from a functional perspective, performance perspective and
dependability (safety and security)
- Assumption: RefInt is not directly re-used in Series Products and is not a singular Safety Element out of Context
- Each Module has to follow the S-CORE process
- Ensure Quality aspects (Quality Management Plan: Compiler errors, SCA, C0/C1, ....) in each of the modules and
- How to deal with stuff from outside? e.g. OpenSOVD
- They need to provide the necessary artefacts as Docu, Safety Manual, etc.
- Or as work-around only: we have to have in S-CORE a maintainer to close the gaps- Assumption of Use of S-CORE RefInt
- as much as possible re-use of the RefInt in Series Product without adaptations
- Assumption of Use of S-CORE RefInt
8 participants
Formal decision record based on discussion during last architecture community workshop: https://github.com/orgs/eclipse-score/discussions/1922#discussioncomment-14871055
This intends to establish a discussion basis for further technical dr's such as:
Important
This PR will be kept open at least until 13th Feb before merging to ensure that necessary reviews can be conducted.