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.
| "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.
Add design decision to enable SCORE features as independent SEooC delivery units in dedicated repositories.