process: add DR-005 for independent feature delivery#2346
process: add DR-005 for independent feature delivery#2346
Conversation
|
The created documentation from the pull request is available at: docu-html |
|
Generate HTML version of the DR: https://eclipse-score.github.io/score/pr-2346/design_decisions/DR-005-process.html |
| This creates the necessity to provide features as independent SEooC | ||
| units. Furthermore, the current repository structure does not allow | ||
| features to be released independently from the platform repository. | ||
|
|
There was a problem hiding this comment.
A lot here seems to depend on the understanding of "feature" and "module". Please, add a clear definition here.
There was a problem hiding this comment.
I am sorry, but for me the "word definitions" are still unclear, especially if it comes to the version 2b. Sub-feature, sub-component. Hard to understand.
| "Integration Repo" ..> "Module Repo" : uses | ||
| "S-Core Repo" -[hidden]d- "Module Repo" | ||
| "Integration Repo" ..> "SW-Module Repo" : uses | ||
| "S-Core Repo" -[hidden]d- "SW-Module Repo" |
There was a problem hiding this comment.
S-CORE, as used allover the reset of the document
arsibo
force-pushed
the
arsibo_dr_feature_as_seooc
branch
from
6997d14 to
9cd5776
Compare
Add design decision to enable SCORE features as independent SEooC delivery units in dedicated repositories (incl. correction of review findings).
arsibo
force-pushed
the
arsibo_dr_feature_as_seooc
branch
from
7c6de66 to
6eb33f3
Compare
arsibo
requested review from
PhilipPartsch,
aschemmel-tech and
pahmann
as code owners
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
see inline comments
| :caption: Alternative 2: Dedicated Feature Repository Architecture | ||
|
|
||
|
|
||
| Alternative 2b: Feature in SW Module Repository with Sub-Features (System of Systems) |
There was a problem hiding this comment.
Missing the use case of a component from another "SW module repo" is needed by "my" feature SEooC. The question here is how the "safety package" (collection of work products including the verification report) for this would look like. In my current understanding we would deliver the safety packages for two "SW module repos" which then would include the feature requirements/architecture/integration test results also for the feature we do not integrate (completely) in "my" Feature SEooC.
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| The platform artifacts are located in the S-CORE platform repository. | ||
| The feature artifacts are located in the SW module repository. |
There was a problem hiding this comment.
Please add something like "A SW module is no architecture element, just a “container” for work products to do a collective versioning/baseline. Especially it is not a component or a set of components as it is currently."
There was a problem hiding this comment.
See here, this is not quite correct, https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html#
Further the project provides Software Modules (red box, middle, 1st column), which can also be developed as a SEooC. A Software Module is defined as a Component (green box, middle, 2nd column) or a set of components realizing a Feature of the platform. In this sense a Software Module is the highest level component in our model. A Software Module represents e.g. executable code or a library.
There was a problem hiding this comment.
The formulation above was discussed and agreed in the meeting on Jan-13. It will need a modification to our current definition as you rightly point out.
|
For me this is highly coupled with #2400. My proposal would be to first decide the working model or at least to discuss both in one meeting |
…d prevent duplicates POC for eclipse-score/score#2346
POC for eclipse-score/score#2346 Replace local path override with git override using branch arsibo_dr_005_poc for score_platform dependency. This allows the build to work with remote branch after pushing.
…e module dependencies POC for eclipse-score/score#2346
POC for eclipse-score/score#2346 Replace local path override with git override using branch arsibo_dr_005_poc for score_platform dependency. This allows the build to work with remote branch after pushing.
POC for eclipse-score/score#2346 Add comprehensive architecture documentation with focus on architecture modeling: - Logging feature (mw-fr_logging) with feature architecture - Component architectures for: - data_router_recorder - datarouter - file_recorder - log_bridge - recorders Note: Documentation templates are not yet completely filled out. Further refinement and completion of templates is required in future iterations.
…ependencies POC for eclipse-score/score#2346 Replace local path overrides with git overrides using branch arsibo_dr_005_poc for: - score_docs_as_code - score_platform - score_baselibs - score_baselibs_rust This allows the build to work with remote branches after pushing.
…ependencies POC for eclipse-score/score#2346 Replace local path overrides with git overrides using branch arsibo_dr_005_poc for: - score_docs_as_code - score_platform - score_baselibs - score_baselibs_rust This allows the build to work with remote branches after pushing.
POC for eclipse-score/score#2346 Replace local path override with git override using branch arsibo_dr_005_poc for score_platform dependency. This allows the build to work with remote branch after pushing.
POC for eclipse-score/score#2346 Replace local path override with git override using branch arsibo_dr_005_poc for score_platform dependency. This allows the build to work with remote branch after pushing.
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
Alternative 2b not approved
|
|
||
| Features bound to platform release cycle, split between platform | ||
| and modules | ||
| - **(+)** |
There was a problem hiding this comment.
The artifacts in the SW-platform are relevant for the "Feature SEooC" still, Stakeholder requirements are the "Assumed Technical Safety Requirements" which need to be mapped to the "System Requirements" of the User. And also the platform wide AoU are relevant and need to be covered by any Feature user. So you would still depend on one platform release version.
| * - Independence of Release / Topic Coherence (How independently can | ||
| features be released and how well are related artifacts kept | ||
| together?) | ||
| - **(-)** |
There was a problem hiding this comment.
In my understanding eclipse-score/tooling#95 proposes a way to produce all needed documentation for a SEooC within one module repo by using also artefacts defined in other used repos including the platform repo. So this would enable also staying with alternative 1.
6 participants
Add design decision to enable SCORE features as independent SEooC delivery units in dedicated repositories.