Date
Participants
Slides
Notes
Ongoing discussions
RK: Component discovery Gaps issue 23. For extension points within the schema. By adding them, other tools would accept them (and ignore). Please take a look. Can start adding extensions to the documentation and classify them.
EF: In Joachim’s request for issue 23, asking Maxim to draft a schema, what are you looking for?
JK: Way to identify a component and need flexibility in classifying. Have a keyword pair. Wanted to try to to “play through” one classification that would meet ST’s needs. Want to agree something - a predefined classification scheme, not free form text.
EF: We can have a deeper look and come back with feedback. Are we all aligned on the principle.
RK: Think it needs some more discussion.
EF: Interesting to have a way to split between identification and classification. One of the advantages of keyword proposal then we end up with something that’s easily backwards-compatible and can help processing by tools.
JK: Don’t necessarily have a clean hierarchy of classes.
RK: Classification - is a “USB driver” a “driver”?
MD: If you want to classify - have several information that we need to store at the same level. If we add a keyword list can all agree on.
RK: Question is how we extend it over time.
JK: Benefit I see is could look for components with keyword “USB” but don’t need to look through hierarchy. Happy to remove all reference to features and call it keywords.
DJ: Think this is related to “taxonomic rank shift” discussed previously - standard ranks. Up to us to choose appropriate number of levels. Could create another level to discriminate between stack, middlewares, drivers etc (see Taxonomic Rank page on Wikipedia)
EF: Identification is attached to existing taxonomy. It’s two different things.
DJ: Retain existing CMSIS taxonomy for identification and add a new taxonomy for classification?
EF: Yes. Means they can evolve separately.
RK: Should taxonomies always be public?
JK: Suggest to park it now and come back with play-throughs or examples
DJ: Not sure if I understand the exact solution. Variants could be solved like dependency conflicts.
RK: Attempt is to make it extensible.
DJ: What if we introduce an element “conflicts”? Referring more to the bundle. Think the feature originally proposed by ST is subset of entities we are discussing since related to API objects not general set of files. Closely related to general configuration problem that we’ve decided to postpone.
JK: Excluding configuration of components.
DK: Bundle variant should be covered in dependencies and not in the classification.
RK: Think we are in alignment to explore public taxonomy category list.
Contribution Topic
JK: How to contribute (slide). Have discussions, proposals and change requests. For design decisions think it’s important to have a GitHub issue first. For larger items it would be good to capture it in Jira, break it down and assign resources to it. We have representatives from companies with write access in Jira and everyone has read access.
EF: On digital signing …
JK: Pascal responded
Tooling - Discussion Item 12
RK: This is pitching the long-term goals. In a yaml file can specify it and get a meaningful editor extension. Have an interactive user help. Could type ‘ST’ and get a list of devices that would match.
EF: You mean to make a prototype?
RK: Yes
JK: In summary it’s not an interactive CLI but specified by a yaml file.
DJ: Agree for the minimal implementation as a yaml file.
PH: Would agree to have something that doesn’t wait for inputs.
EF: Think it would simplify the initial end goal.