Conversation
|
|
|
The created documentation from the pull request is available at: docu-html |
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
Generally I like the content very much. Inline are some improvement proposals.
| .. ******************************************************************************* | ||
|
|
||
| ======================================================== | ||
| Eclipse SCORE - Complete Tool List for Safety Evaluation |
There was a problem hiding this comment.
If we want to document used libraries / modules of S-CORE and tools used in one document, I would adapt this headline. But we also could split into two?
There was a problem hiding this comment.
Stick only to tools
| :Organization: Eclipse Foundation | ||
| :Project: Eclipse SCORE (Scalable & Modular COmponent Runtime Environment) | ||
| :Purpose: Comprehensive tool inventory for safety classification and evaluation | ||
|
|
There was a problem hiding this comment.
This looks like a document header, but it is not the one the document mgt process defines. Maybe this is a document realizing a draft version of the the wp__sw_platform_sbom?
| * - ID | ||
| - Tool Name | ||
| - Version | ||
| - TCL |
There was a problem hiding this comment.
Do we want to document the TCL again? Not only in https://eclipse-score.github.io/score/main/score_tools/index.html?
There was a problem hiding this comment.
Removed, compare score_tools_evaluation_list
| :header-rows: 1 | ||
| :widths: 5 15 10 10 10 10 40 | ||
|
|
||
| * - ID |
There was a problem hiding this comment.
Missing here: CodeQL
| - TBD | ||
| - YES | ||
| - YES | ||
| - Process description tools (ASPICE 4.0, ISO 26262, ISO 21434, ISO PAS 8926) |
There was a problem hiding this comment.
these are not tools
| - Version | ||
| - Purpose | ||
| * - 52 | ||
| - Boost |
There was a problem hiding this comment.
Could we also show where this is used? Would be also generally helpful for new tools found.
There was a problem hiding this comment.
As said, will remove that here, should be part of SBOM information
| * - Language Servers | ||
| - 3 | ||
|
|
||
| Recommended Evaluation Priority |
There was a problem hiding this comment.
Do we want to describe this process description / tool qualification planning here and not in the PMP's tool management plan?
There was a problem hiding this comment.
Will removed that here
| - S-CORE Bazel Registry: https://github.com/eclipse-score/bazel_registry | ||
| - S-CORE Documentation: https://eclipse-score.github.io/score | ||
|
|
||
| Document History |
There was a problem hiding this comment.
Not according to our doc mgt process
| - LOW | ||
| - YES | ||
| - YES | ||
| - Main build system (documented in score_tools) |
There was a problem hiding this comment.
I'm not sure what is meant here, but score_tools is actually the approach to run tools without bazel ;-)
| This document provides a comprehensive initial inventory of all tools used across the Eclipse SCORE project | ||
| and its 68+ repositories under https://github.com/eclipse-score. The list includes build tools, | ||
| compilers, static analyzers, testing frameworks, documentation generators, and supporting utilities. |
There was a problem hiding this comment.
Is this 1st level dependencies or do we list all of them?
e.g. reference integration is using score_tool_X.
score_tool_X includes non_score_lib_Y
score_tool_X uses non_score_tool_Z for testing
I don't know if I can figure out a good example...
reference integration is compiled in a devcontainer.
devcontainer is defined to include "feature/python".
"feature/python" will install python.
python will auto-install pip.
Note: taking transitive dependencies into account github currently detects 1122 dependencies in score.
There was a problem hiding this comment.
We list only tools used to produce the final delivery. Dependencies of modules/lib etc should be done by the SBOM only, revised therefore headline
| This document provides a comprehensive initial inventory of all tools used across the Eclipse SCORE project | ||
| and its 68+ repositories under https://github.com/eclipse-score. The list includes build tools, | ||
| compilers, static analyzers, testing frameworks, documentation generators, and supporting utilities. |
There was a problem hiding this comment.
What about pipelines (automations)? Do we exclude them as we assume a "final vehicle release" will not happen with these automations?
There was a problem hiding this comment.
Not clear what you mean, compare new score_tool_evaluation list, kept only statement initial inventory list
| - YES | ||
| - Python static type checker (99% test coverage) | ||
| * - 27 | ||
| - pylint |
There was a problem hiding this comment.
pylint is currently only used by bazel-tools-python which is not used by S-CORE.
There was a problem hiding this comment.
Then we make mark it as not relevant in the list score_tools_evaluation_list
| - TBD | ||
| - Starlark (Bazel) language server | ||
| * - 33 | ||
| - basedpyright |
There was a problem hiding this comment.
move to python section?! We use it for all infrastructure python code.
| - TBD | ||
| - YES | ||
| - YES | ||
| - Python documentation generator (underlying Doc-as-Code) |
There was a problem hiding this comment.
Docs-as-code has ~100 dependencies. Sphinx may not even be the biggest one here. Should we track none of them or all of them? See my first question :)
https://github.com/eclipse-score/docs-as-code/blob/main/src/requirements.txt
There was a problem hiding this comment.
No, will not track them in this list
| - YES | ||
| - License analysis tool | ||
| * - 51 | ||
| - REUSE |
There was a problem hiding this comment.
We do not yet actively use reuse, especially not for compliance checking. We would use it for enforcing license consistency.
We ask eclipse for a license clarification and classification. Then Eclipse iplab is using reuse (among other tools like clearlydefined) to analyze 3rd party licenses.
| - TBD | ||
| - PlantUML integration for Sphinx | ||
|
|
||
| S-CORE Custom Tooling |
There was a problem hiding this comment.
Would we consider these custom tools? Do we consider every action a custom tool?
- more-disk-space to clean up disk space on github runners
- apt-install to install dependencies on github runners
- dash-license-scan is OUR tool for license scanning. It uses dash-license INTERNALLY.
There was a problem hiding this comment.
No, only if influencing our delivery, not apt-install
| * - 71 | ||
| - score_bazel_platforms | ||
| - Latest | ||
| - Platform definitions (x86_64-qnx, x86_64-linux, etc.) |
There was a problem hiding this comment.
It's definitions. Not a tool?
| :widths: 5 20 15 50 | ||
|
|
||
| * - ID | ||
| - Language Server |
There was a problem hiding this comment.
+basedpyright for python
+esbonio for docs-as-code
+ubCode for docs-as-code
+a dozen more that come with the IDE :/
Tool list for validation of tools within S-CORE Basis for Tool Evaluation Lists Basis for SBOM Tool as possible output report
masc2023
force-pushed
the
masc2023_add_tool_list
branch
from
e030f5c to
9e756e7
Compare
3 participants
Tool list for validation of tools within S-CORE
Basis for Tool Evaluation Lists
Basis for SBOM Tool as possible output report