https://wiki.spdx.org/index.php?action=history&feed=atom&title=Technical_Team%2FMinutes%2F2020-04-14 2026-05-07T12:33:08Z Revision history for this page on the wiki MediaWiki 1.23.13 https://wiki.spdx.org/index.php?title=Technical_Team/Minutes/2020-04-14&diff=4816&oldid=prev 2020-04-14T18:07:04Z

<p>Created page with &quot;April 14, 2020 == Attendees == * Alexios Zavras * Nisha Kumar * Steve Winslow * Kate Stewart * Santiago * William Bartholomew * Gary O’Neall * Peter Shin * Thomas Steenberg...&quot;</p> <p><b>New page</b></p><div>April 14, 2020<br /> == Attendees ==<br /> * Alexios Zavras <br /> * Nisha Kumar<br /> * Steve Winslow<br /> * Kate Stewart<br /> * Santiago<br /> * William Bartholomew<br /> * Gary O’Neall<br /> * Peter Shin<br /> * Thomas Steenbergen<br /> <br /> ==SPDX 2.2==<br /> * Broken diagrams<br /> ** Kate is fixing the first the first one<br /> ** Gary will update the model next week, we can go ahead and send out before the update if needed<br /> * ISO write onboard<br /> ** Will do formatting<br /> ** Need to add examples<br /> ** Will invite the text writer into next call<br /> <br /> ==Profiles==<br /> * Add an array at the document level with profiles; don’t need base since it is implied<br /> * Enum would require update spec, having a String would be more flexible<br /> * Another possibility is to assume a profile based on the “namespace” or what items<br /> * Consensus Profiles “set” with enumeration<br /> * Versioning of profiles<br /> ** Should each profile have a version – similar to the license list?<br /> ** Would we release different profiles at different times?<br /> ** Thomas expressed interest in keeping it simple, only use SPDX versions – keep profile versions synchronized with SPDX version<br /> ** Nisha raised the possibility of keeping a document manifest<br /> ** We could support manifests using external document references<br /> * Discussion on simplicity<br /> ** All agree this should be a guiding principle – we would want 3.0 to be less complex than 2.2<br /> ** Discussion on how important human writable/readable<br /> ** Are there requirements to make sure we don’t make it “too simple”?<br /> *** We can use the use cases to confirm?<br /> *** Peter will create a document<br /> <br /> ==Linking and relationships==<br /> * Links will be part of the base profile<br /> * Provenance elements part of the relationship<br /> * Consider having provenance information as properties of the relationships<br /> * Profiles could still describe the relationship required properties<br /> * Concept of strong and weak relationships<br /> ** Strong relationship would include the provenance information<br /> * Inheritance vs containing<br /> ** Inheritance would be less disruptive<br /> ** Signing could be impacted<br /> ** Should we pull in Grafeas to verify use cases and deployability<br /> ** Schedule 2 Tuesday’s from now<br /> <br /> ==Software lifecycle proposal==<br /> * Proposal for a format for SCM proposal <br /> * Similar to software product lifecycle<br /> * Very similar to work being done by Santiago<br /> * Scope is not just license compatibility, but also contractual compatibility<br /> * Would be a profile<br /> * Design principle – prefer SPDX stick to facts<br /> <br /> [[Category:Technical|Minutes]]<br /> [[Category:Minutes]]</div>

Goneall