THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Technical Team/Minutes/2020-04-14

From SPDX Wiki
< Technical Team‎ | Minutes
Revision as of 18:07, 14 April 2020 by Goneall (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

April 14, 2020

Attendees

  • Alexios Zavras
  • Nisha Kumar
  • Steve Winslow
  • Kate Stewart
  • Santiago
  • William Bartholomew
  • Gary O’Neall
  • Peter Shin
  • Thomas Steenbergen

SPDX 2.2

  • Broken diagrams
    • Kate is fixing the first the first one
    • Gary will update the model next week, we can go ahead and send out before the update if needed
  • ISO write onboard
    • Will do formatting
    • Need to add examples
    • Will invite the text writer into next call

Profiles

  • Add an array at the document level with profiles; don’t need base since it is implied
  • Enum would require update spec, having a String would be more flexible
  • Another possibility is to assume a profile based on the “namespace” or what items
  • Consensus Profiles “set” with enumeration
  • Versioning of profiles
    • Should each profile have a version – similar to the license list?
    • Would we release different profiles at different times?
    • Thomas expressed interest in keeping it simple, only use SPDX versions – keep profile versions synchronized with SPDX version
    • Nisha raised the possibility of keeping a document manifest
    • We could support manifests using external document references
  • Discussion on simplicity
    • All agree this should be a guiding principle – we would want 3.0 to be less complex than 2.2
    • Discussion on how important human writable/readable
    • Are there requirements to make sure we don’t make it “too simple”?
      • We can use the use cases to confirm?
      • Peter will create a document

Linking and relationships

  • Links will be part of the base profile
  • Provenance elements part of the relationship
  • Consider having provenance information as properties of the relationships
  • Profiles could still describe the relationship required properties
  • Concept of strong and weak relationships
    • Strong relationship would include the provenance information
  • Inheritance vs containing
    • Inheritance would be less disruptive
    • Signing could be impacted
    • Should we pull in Grafeas to verify use cases and deployability
    • Schedule 2 Tuesday’s from now

Software lifecycle proposal

  • Proposal for a format for SCM proposal
  • Similar to software product lifecycle
  • Very similar to work being done by Santiago
  • Scope is not just license compatibility, but also contractual compatibility
  • Would be a profile
  • Design principle – prefer SPDX stick to facts