Skip to content

Commit

Permalink
Update existing links to tech minutes
Browse files Browse the repository at this point in the history
Signed-off-by: Arthit Suriyawongkul <[email protected]>
  • Loading branch information
bact authored and goneall committed Oct 16, 2024
1 parent a2ae8fa commit 857d998
Show file tree
Hide file tree
Showing 3 changed files with 3 additions and 3 deletions.
2 changes: 1 addition & 1 deletion tech/2020/2020-12-01.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ SPDX Tech Team Minutes, December 01, 2020
* Integrity & Hash
* External Reference and Annotation.

* from https://github.com/spdx/meetings/blob/master/tech/2020-11-03.md:
 
Annotation - should they be a sub-class of SpdxElement?

* from https://github.com/spdx/meetings/blob/master/tech/2020/2020-11-03.md:
 
Annotation - should they be a sub-class of SpdxElement?

* Kate: probably not. We can probably continue with the current version and circle back if we find a good use case for it.
* Annotation is way of extending - Jorge will provide feedback if what have.

Expand Down
2 changes: 1 addition & 1 deletion tech/2022/2022-03-01.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,7 @@ https://github.com/spdx/spdx-spec/milestone/6
* Heading back to meta question of do you have to have a document.
* Challenge is signing an element. Logical model vs. physical manifestation.
* Verifying integrity of "bits", "bits" is a physical thing. William points could be stream of bytes that is hashed & signed. ie. dynamically generated by API, shared without persisting.
* Sebastian reminds of Jan 11 meeting (https://github.com/spdx/meetings/blob/main/tech/2022-01-11.md), parallel subgroup meeting to discussion. Sebastian will send out a poll to tech list, for folks to sign up for a meeting and express preference.
* Sebastian reminds of Jan 11 meeting (https://github.com/spdx/meetings/blob/main/tech/2022/2022-01-11.md), parallel subgroup meeting to discussion. Sebastian will send out a poll to tech list, for folks to sign up for a meeting and express preference.
* Gary on dealing with topic for 7 years, so have a specific proposal that is implementable before we decide to do it. Nisha agrees with subgroup for serialization discussion. Curious why it is separate? William says because support different formats - ie. JSON vs. YAML have the same signature? Can change signatures over logical info. Signing only at document level - massive document. Goal is to be able to abstract out parts and maintain integrity. David points out that element model lets this possible.
* Conclusion: Signatures fall under integrity, but not considered blocking.

Expand Down
2 changes: 1 addition & 1 deletion tech/2022/2022-11-04.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@
* William: there is an alternate way of thinking about this, that licensing isn't a property of the artifact but there's a separate "LicenseEvaluation" class that references the artifact. This allows you to have multiple evaluations by different people and for them to evolve over time. Just like vulnerabilities. Own identifier with license information, and then could associate. Artifact tracking implications.
* Sean: Just for clarity, everything I was saying was generally applicable across all profiles. I was not talking about the licensing use cases specifically.
* Maximillian: Concern about the use-case focus for this discussion, real world vs. database. re: extending the model, concern about composibility - AI vs. Licensing vs. Build. Concern that the extend approach will not be as compositional.
* Gary: Concern that it will increase complexity for the licensing use cases by heading if not using properties. Queries, extensions/shapes will get things more complicated. Please use metric of complexity when discussing this. https://github.com/spdx/meetings/blob/main/tech/2021-02-16.md
* Gary: Concern that it will increase complexity for the licensing use cases by heading if not using properties. Queries, extensions/shapes will get things more complicated. Please use metric of complexity when discussing this. https://github.com/spdx/meetings/blob/main/tech/2021/2021-02-16.md
* Sean: Want to let sub communities focus on their own profile, without impacting other profiles. Interpreting profile, what part of the model will you use, and a namespace with in it. Assertion of which parts of the model were relevant for a particular area. Different than adding to core.
* Bob: Compliance points for profiles.
* Sean: If property was defined in core. You can do this by having a namespace as the extension of profile.
Expand Down

0 comments on commit 857d998

Please sign in to comment.