Ulf: one idea is when larger
pieces of change requests are submitted, ideally based on
previous discussion within the group, if it is more right than
wrong it should be accepted
... there may be pieces that make further refinement, lodging
new issues for discussion
... one argument for this model is to avoid work getting
stuck
... typically the commenter with the objection needs to revise
for acceptance
... comments are welcome of course
... it can be frustrating and discouraging at present
Peter: some of the comments are
difficult to interpret
... how do we determine how to handle opposing view points?
Daniel: you can make a concrete proposal and then work on that piece of the spec
Magnus: in one way it is good to
get submissions and get them in. it is a draft after all so
agree erring on allowing may be better
... on the other hand, we may have special interests against
specific pull requests
... how to tell the situation we are in?
Ulf: there will be diverging views for sure
Magnus: we had same situation with VW pull requests outstanding since last Spring
Daniel: there were comments on
that pull request that weren't answered, sometimes discussed on
WG call
... we can mark things on merge
Magnus: we can set a TTL on pull requests. if there is no feedback within a timeframe it is up for decision to accept or reject
Ulf: we do not want them
hanging
... what is the criteria for rejection
Ted: what Ulf described is a
viable path provided issues are create for objections raised.
another would be smaller pull requests. we can also accept some
commits for a PR and leave others outstanding for subsequent PR
and discussion
... we have a minimum amount of time to review PR, we should
define a max too
Peter: how about 14 days for maximum?
Ted: ok with me with exception of August and December
Magnus: work schedules can get in the way, 3 weeks maybe better
Peter: OK
... then what? what is our process?
Ted: announce to WG intention to
decide and next WG call, encourage comments on PR
... decision will be either except with reservations noted and
corresponding issues created, accept some of the commits,
reject
https://github.com/w3c/automotive/pull/314#partial-pull-merging
https://github.com/w3c/automotive/pull/314/files/8f3154b3731381922444dd0ae51cb16bb2604593
Ted: splitting doc is unrelated to PR and a separate issue
Magnus: that should be discussed and a separate PR
Ulf: agree, if it makes sense we
can do later as Ted commented
... most of the changes were to core, transport doc mostly
examples and updated to reflect
Daniel: let's use the proposed
rule from earlier, announce intent to resolve next week and
accept PR as is
... subsequent issues and PR can be made
... structural changes may happen frequently
Peter: structural issue at this stage not enough to block
https://github.com/w3c/automotive/pull/315
Daniel: the taxonomies are just
examples, core issue is whether the access method can handle
it
... I still think we should do more than "could or may"
Peter: for anything other than vehicle signals, taxonomy needs to be clear
Ted: the group is clear in commitment to VSS for vehicle signals. for other domains what we need are general rules for data models to follow to be compatible with Gen2
Daniel: as an automotive group,
it should have some relation. you need to define what to expect
for sure. VSS is an example and can have private branches
... for the domains I would hope to have link to vehicle work.
media doesn't have to be in VSS but needs to be described and a
common format - JSON with a data structure
... it can be defined elsewhere but how to link them?
Ted: registry and service discovery for client applications to me makes more sense than a large single tree. we kind of went through this with JLR some time ago, wanting to encapsulate everything in VSS. we want to be able to support additional data domains created elsewhere but exposed as services within the vehicle if they follow our taxonomy rules
[Ulf shares screen]
Ulf: this is for a related but
separate API for supporting more dynamic registry
... this is not a frequent operation like a new playlist. it
would require a different level of security
... ability to add/delete services besides what Gen2 provides
and based on architecture
... routing to pertinent service based on tree
Daniel: best example is GraphQL,
you do not want to expose the service underneath
necessarily
... you can support legacy services via abstraction
Ted: but can be unwieldy in-vehicle apps for JSON, getting back all data and more than you need can be a performance problem
Daniel: that is a bad request
then and you can have safeguards on your service
... you can have things separate but define the relationship at
the top level, how it relates to the vehicle
[also want understanding of registry from ViWi within group]
[adjourned]