THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Difference between revisions of "Technical Team/Minutes/2013-04-16"
From SPDX Wiki
< Technical Team | Minutes
(→Participants) |
Bschineller (Talk | contribs) |
||
| (12 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == '''Agenda for Technical Team meeting at Linux Collab 4/16''' == | |
| − | + | === Participants === | |
| − | * Gary O'Neall | + | * Gary O'Neall (Source Auditor) |
| − | * Jack Manbeck | + | * Jack Manbeck (TI) |
| − | * Kate Stewart | + | * Kate Stewart (Linaro) |
| − | * | + | * Dennis Clark (NexB) |
| + | * Kirsten Newcomer (Blackduck) | ||
| + | * Liang Cao (UNO) | ||
| + | * Martin Michelmayer (HP) | ||
| + | * Daniel German (UVic) | ||
| + | * Norman Glaude (protecode) | ||
| + | * Beth "Pidge" Flanagan (intel/yocto) | ||
| + | * Michael Neuling (NexB) | ||
| + | * Daniel Coley (Juniper) | ||
| + | * Brandon (Cisco) | ||
| − | + | === Agenda === | |
* Best Practices/Usage of SPEC document | * Best Practices/Usage of SPEC document | ||
| − | + | ** get to outline and see who's interest in participaing in filling it in. | |
* SPDX 2.0 planning | * SPDX 2.0 planning | ||
| − | + | ** Review straw man model - Gary | |
| − | + | ** Instance diagram review? - Jack/Bill | |
| − | + | ** Distribution of packages use case | |
| − | + | *** will straw man handle? - cross check with Yocto | |
| − | + | *** reasonable abstraction of elements - consistent | |
| − | + | ** Other key use cases want to cross check? | |
| − | ==== | + | == Minutes == |
| + | |||
| + | ===Reviewed Proposed Merged model. === | ||
| + | * Current model: http://wiki.spdx.org/index.php/File:Model-4-16-2013.png | ||
| + | * Decision to merge Document and Element. | ||
| + | * Decision to consider Document, Package, File, Snippet as sub classes of Elements. | ||
| + | * Snippets: byte ranges as sub class of Element. Multiple elements, overlap range. | ||
| + | ** Not required, but permit and support, as sub case of elements. | ||
| + | ** File is 0..#(EOF byte). | ||
| + | ** snippet is '''only''' valid if it has a relationship to a file. "is part of". | ||
| + | |||
| + | === SPDX Element=== | ||
| + | * relationship: see Relationship Enumeration (w/Verification code of other element) | ||
| + | * usage : see Element Usage Enumeration | ||
| + | * license: see Licence classe | ||
| + | * verification code | ||
| + | * comment (by creator) 0:1 | ||
| + | * annotation (by reviewer) 0:* - text, property of reviewer | ||
| + | * sub classes: | ||
| + | ** Document: | ||
| + | ** Package: | ||
| + | ** File: | ||
| + | ** Snippet: | ||
| + | |||
| + | ===Reviewer=== | ||
| + | * property of a Document. | ||
| + | * comments are reflected as annotation | ||
| + | |||
| + | ===Relationship Enumeration=== | ||
| + | * "is part of" | ||
| + | * "contains" | ||
| + | * "generated from" | ||
| + | * "generates" | ||
| + | * "is same as" -- snippet discussion | ||
| + | * "modifies" | ||
| + | * "modified by" | ||
| + | * "revision of" -- may want to evolove reviewer, document, code, auditor, intent of modifier.... | ||
| + | |||
| + | ?? how represent a revision of an SPDX file? provenance, adjustments?? derived from. | ||
| + | |||
| + | ===Element Usage Enumeration=== | ||
| + | * source | ||
| + | * executable | ||
| + | * dynamic library | ||
| + | * static library | ||
| + | * data files (image, audio, visuals, etc.) | ||
| + | * test (data, frameworks) | ||
| + | * build tools | ||
| + | * documentation (man, README, SPDX, DEP5, etc.) | ||
| + | * reference implementation | ||
| + | * | ||
| + | |||
| + | '''WORKFLOW''' is a 3.1 issue. | ||
Latest revision as of 18:20, 23 April 2013
Contents
Agenda for Technical Team meeting at Linux Collab 4/16
Participants
- Gary O'Neall (Source Auditor)
- Jack Manbeck (TI)
- Kate Stewart (Linaro)
- Dennis Clark (NexB)
- Kirsten Newcomer (Blackduck)
- Liang Cao (UNO)
- Martin Michelmayer (HP)
- Daniel German (UVic)
- Norman Glaude (protecode)
- Beth "Pidge" Flanagan (intel/yocto)
- Michael Neuling (NexB)
- Daniel Coley (Juniper)
- Brandon (Cisco)
Agenda
- Best Practices/Usage of SPEC document
- get to outline and see who's interest in participaing in filling it in.
- SPDX 2.0 planning
- Review straw man model - Gary
- Instance diagram review? - Jack/Bill
- Distribution of packages use case
- will straw man handle? - cross check with Yocto
- reasonable abstraction of elements - consistent
- Other key use cases want to cross check?
Minutes
Reviewed Proposed Merged model.
- Current model: http://wiki.spdx.org/index.php/File:Model-4-16-2013.png
- Decision to merge Document and Element.
- Decision to consider Document, Package, File, Snippet as sub classes of Elements.
- Snippets: byte ranges as sub class of Element. Multiple elements, overlap range.
- Not required, but permit and support, as sub case of elements.
- File is 0..#(EOF byte).
- snippet is only valid if it has a relationship to a file. "is part of".
SPDX Element
- relationship: see Relationship Enumeration (w/Verification code of other element)
- usage : see Element Usage Enumeration
- license: see Licence classe
- verification code
- comment (by creator) 0:1
- annotation (by reviewer) 0:* - text, property of reviewer
- sub classes:
- Document:
- Package:
- File:
- Snippet:
Reviewer
- property of a Document.
- comments are reflected as annotation
Relationship Enumeration
- "is part of"
- "contains"
- "generated from"
- "generates"
- "is same as" -- snippet discussion
- "modifies"
- "modified by"
- "revision of" -- may want to evolove reviewer, document, code, auditor, intent of modifier....
?? how represent a revision of an SPDX file? provenance, adjustments?? derived from.
Element Usage Enumeration
- source
- executable
- dynamic library
- static library
- data files (image, audio, visuals, etc.)
- test (data, frameworks)
- build tools
- documentation (man, README, SPDX, DEP5, etc.)
- reference implementation
WORKFLOW is a 3.1 issue.
