Transition from Arm Shadowfax Componentisation to Open-CMSIS-Pack WG
All meeting material (including the recording) will be public as will other project materials
Note that slides said “Open Governance” but should state something like “Open (Public) Project”
DJ: For helper tools, should we start implementation in C++ or it doesn’t matter which language? JK: Think at the moment make most impact if we benefit from what people have started. Language could be secondary. MD: Agree to go on existing code on first step
JK: New requirements straight into Jira or continue with GitHub issues first? We need as a group to figure out the process
DJ: In the case of CMSIS Pack API represents expected functionality but may be an alternative approach where it just defines the interface. Should be considered in design of components and should say what is expected. JK: Interface should have the ability to say if features are implemented or not implemented - do we have that in the HAL. See what the reaction from MD’s team. JA: Open CMSIS Pack point of view looking for describing certain features of interface as part of component metadata when we’re solving dependencies? MD: Details of what functionality API offers and further, yes for solving dependencies. DJ: Need for differentiation of different features of peripherals. JA: Captured in a discussion somewhere? DJ: Not yet. JK: (Generally) how to keep in sync with HAL and test project - do we have people joining both, or agree on a periodic syncing up? JK: Back to capturing this, what’s the problem we’re trying to solve? Action MD to capture the User Story
DJ: CBundle issue - have an alternative approach and can be effectively removed from the standard? JK: Ok to deprecate it - expect tools to be able to handle it. DJ: Meant we offer the alternative for dependencies. JK: Believe ST interested to show how components belong together as a Group. How to express that components ‘belong’ somehow. Dependencies may not ‘display it’.