...
Meeting notes 2024-02-20:
Meeting notes 2024-02-13:
- AMM VSS Topics - Topic proposals
- VSS Working Session 9.45-11.30 Wednesday (DEG also have some time for working sessions)
- Anything particular someone wants to bring up or present?
- Suggestions:
Release Planning- See
- Erik: Instance handling and "VSS Expanded Tree" - How do you want to handle instances? How do you handle instances today
issues689 - See notes in issue
Branch usage: - Issue handling - general
- Example: Emission standards - 704https://github.com/COVESA/vehicle_signal_specification/pullissues/707394
- Possible improvement area, but no-one seems to be interesting actively driving it
- Issues are of different types today, some maybe fit better as discussion, but also then we have a question on how long we want them to exist
- Possible improvement areas
- Actual limitations/error (which no-one intends to fix)
- Proposed Handling (to be discussed):
- Close issues after 6 months of inactivity
- If we have agreed/decided something in the discussion - reflect that in VSS or VSS-tools documentation before closing the issues
- If the issue concerns a known limitation/error, then document that in a file for known limitations in the repo
- Example: Generator
vspec2something
cannot handle the signal name ggg
as that is a a reserved word in something
.
Meeting notes 2024-02-13:
- Release Planning
- Branch usage:
- Release Instruction updated according to discussion.
- Erik: Suggesting the following issues/PRs shall be closed at next meeting unless there are comments/remarks
- Please review, items above will be closed before next meeting unless comments
- AP Erik: Add note in those
- Please review, items above will be closed before next meeting unless comments
- AP Erik: Add note in those items
- Unit handling
- Wheel speed - and possibly a wider discussion on "overlapping signals"Instance handling (Left/Right vs Driver/Paseenger)
- Android tooling
- https://github.com/COVESA/vss-tools/issues/192
- Erik:
- My assumption is that we want to keep the work but that no-one intends to create a real tool out of it in the next year(s)
- Suggestions:
- Create a better branch name and add a wiki page explaining purpose of the branch
- Or integrate it into current as "prototype"
- MoM: Think about it, discussion to be continued
- Use of discussions instead of issues
- Instance handling (Left/Right vs Driver/Paseenger)Issue handling - general
- What to do with issues where there has not been any progress in many months
- Keep forever or decide on an auto-close policy?
- Should be doable at least for suggestions/discussions
- For limitations/defects - possibly manage elsewhere? Like in documentation for the related tool.
- Example: Signal Accuracy - https://github.com/COVESA/vehicle_signal_specification/issuespull/105
- Possible improvement area, but no-one seems to be interesting actively driving it
Example: Emission standards - 718
- Android tooling
- https://github.com/COVESA/vehicle_signal_specificationvss-tools/issues/394192
- Erik:
- My assumption is that we want to keep the work but that
- Possible improvement area, but no-one seems to be interesting actively driving itintends to create a real tool out of it in the next year(s)
- Suggestions:
- Create a better branch name and add a wiki page explaining purpose of the branch
- Or integrate it into current as "prototype"
- MoM: Think about it, discussion to be continued
- Use of discussions instead of issues
- Discussion started at https://github.com/COVESA/vehicle_signal_specification/discussions/715
- Nick: Discussion could be used for more informal discussions, Q&A,
- Erik: But if so not necessarily something to discuss at this meeting
- Issues are of different types today, some maybe fit better as discussion, but also then we have a question on how long we want them to exist
- Possible improvement areas
- Actual limitations/error (which no-one intends to fix)
- Proposed Handling (to be discussed):
- Close issues after 6 months of inactivity
- If we have agreed/decided something in the discussion - reflect that in VSS or VSS-tools documentation before closing the issues
If the issue concerns a known limitation/error, then document that in a file for known limitations in the repoExample: Generator vspec2something
cannot handle the signal name ggg
as that is a a reserved word in something
.
Meeting notes 2024-02-06:
...
{"serverDuration": 125, "requestCorrelationId": "6accd8f4b8213ec3"}