Versions Compared

Old Version 49

changes.mady.by.user Erik Jaegervall

Saved on

compared with

New Version 50

changes.mady.by.user Erik Jaegervall

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Agenda discussion - anything that needs to be added?
  • Prioritized topics
    • Structs Status
      • IDL: https://github.com/COVESA/vss-tools/pull/262
        • Related: https://github.com/COVESA/vehicle_signal_specification/pull/576/files
        • Discussion:
          • Sebastian: Proposal is a bit different, new concept, nothing prevents merging PR from Krishna so old style converter support structs, or wait with both
          • Neil: Do we want to restruct existing signals in catalog
          • Krishna: Not yet
          • Sebastian - but do we want hints, if tools are "perfect"?
          • Adnan: Could be an idea to collect starting points for struct candidates (after 4.0)
          • Ulf: A signal represent a datapoint, captured at a specific time, similar approach for structs, all properties within the struct are all captured at the same point in them. fits well to GPS, but not for example door/window signals as they are not captured at same point in time.
        • Decision: Do not add IDL for 4.0
      • For VSS 4.0 - status (to be confirmed):
        • Done: Protobuf, JSON, CSV, Yaml
        • Ongoing: DDSIDL
        • Not done: Overlays, Multi -vt, Franca, Binary, Ttl (contrib), Graphql
        • Needs revisit: Documentation (to indicate status)
      • Discussion:
        • Sebastian: What is our long term approach - will struct support in long run be added to Franca, Binary, Ttl (contrib), Graphql
        • Krishna: Needs expertise support
        • Ulf: Binary will come a few weeks after AMM
        • Pierre: What if we later detect if we need to change syntax of structs to support e.g. Graphql
        • Krishna: Seems to be acceptance of releasing VSS 4.0 with limitations, but fast resolving of remaining topics wanted
        • Erik: Ok to relase VSS 4.0, plan remaining tools/limitations to VSS 4.1
        • Daniel: Could possibly contribute to TTL, dependency to VSSo, refactoring discussion in progress
        • Neil: Have we an idea what signals should be put in struct
        • Stephen: Not intending to refactor existing tree. Best practices document needed.
        • Erik: What we have said so far - structs shall be restrictevly used in standard catalog, possible candidate Position (lat/lon)
        • Daniel: Not clear to me when to use struct vs aggregate. Risk using aggregate on branches if there is no rule-set to branches. There should simple rule-set for branches in general. No clear criteria used as of today.
        • Erik: branches as of today is mostly to get unique names
        • Krishna: Overlays and doc can be fixed for relase, but can we release withou strucs
    • Release 4.0 PlanningRelease 4.0 Planning
      • Agree on what needs to be in - which PRs/features
      • Proposal
        • Feature Freeze April 27th (just after AMM)
        • Pre-release/Release-candidate to be released first week of May
          • To be done by Erik
        • Actual release two weeks later
        • Any fixes (PRs) needed for VSS 4.0 after release candidate must be directed to specific branch (release/4.0)
          • Erik to describe release candidate workflow
    • Screen off PR - https://github.com/COVESA/vehicle_signal_specification/pull/577
      • How to represent "off time" - duration or absolute time?
        • Duration in seconds
  • Decision on old open PRs
  • Open Pull Requests VSS
    • Please review, minor ones will be merged next week unless there are remarks
  • Open Pull Requests VSS-Tools
    • Please review, minor ones will be merged next week unless there are remarks
  • Issues VSS
  • Issues VSS-Tools
  • Prioritized topics for next meeting
    • VSS 4.0 release planning
      • Remaining features
      • Date for release and release candidate

...