\uD83D\uDC65 Participants
(To fill from Google meeting report)
Slides
Meeting Notes
Specification Change Board Review
#24
JK: Laurent asked the question why license could be associated with API definition. The API could be associated with a different license.
FR: PKCS#11 is an example - the API has one license but your implementation can have another.
EF: So can keep this independent?
JK: Yes.
#111
JK: Agree - should we decouple the board extension vs general extensions?
FR: Maybe a specific need - why would a software component depend on a board
JK: Board could maybe have certain flash or hardware module - in csolution may want to associate a specific layer with a specific board. What was the usecase that triggered this?
HS: Have a component/flash/external chips that are board specific - so we have a software component only applicable to the board
EF: It’s the board or the part/component on the board?
HS: Specific for the board.
#95
JK: Wanted to have more details on this.
DJ: Understood it might be an optional parameter.
JK: Set this for review?
#124
FR: Think we need one source of information - if we go for pdsc then we get rid or rzone. There is a duplicate of information.
JK: Ok to keep open for another week?
EF/FR: Yes
#25
JK: Would be good for people to review - so we can have changelog files associated with components on top of the release notes file
#112
FR: Interest also from ST’s side. Happy to discuss with NXP colleagues.
JK: Helpful if you can self-organise. Anyone else interested - please leave a comment in the issue if you want to be involved.
#120
JK: Should we take this to the review?
EF: Yes … can also look internally to see if we are able to share more proposals.
Add <csolution> element to *.PDSC format
JK: Have example in GitHub - a TF-M build
HS: Don’t know how tools will deal with this information.
JK: Don’t have an immediate answer how it would be represented in IDE. Will take it back as an action to visualise a potential way.
AOB:
#179 discussion
Meeting Recording
(paste recording)