Technical Team/Minutes/2018-07-17

From SPDX Wiki
Jump to: navigation, search

July 17, 2018

Attendees

  • Jim Hutchinson
  • Tushar Mittal
  • Ndip Tanyi
  • Steve Winslow
  • Kate Stewart
  • Thomas Steenberg


SPDX GSoC Updates

  • NDip – clarifying travis CI with Gary last week.

Tests for plugin itself. Working on unit tests. Example projects have been used with plug in. Worry: how interact with generated during the tests, solved.

  • Tushar – Sorry my internet was not stable, so posting my work updates here. Last week I completed the diff feature, which the user can use to review the changes and the validate feature which validates the XML text against the license schema. Currently there is a small bugs in the diff feature and also I need to implement pulling of the schema from the repo when user uses the validate feature. For the pull request feature I asked one of the github members, so he said that one bot account is allowed for the users and organizations. So I'll be exploring the Github apps and figuring out which method works better. Will be post my views on that.
  • Yash - see Gitter
  • Gallo – see Gitter


SPDX 2.1.1 Version of Specification

  • Thomas working through options PDF generation, issue with hard line breaks.

SPDX 2.2 - Representing JSON / YAML / XML

  • Preference from the participants was to move away from documenting each format for each field, and only document when special case information is needed. Now that we have the specification on github, and rendered on https://spdx.github.io/spdx-spec/ we have more options.
  • Instead provide full examples for each section of the 5 formats for per chapter longer examples. Highlight “gotchas”, but in interface of web page, show real examples. showing full thing. YAML, JSON, XML, RDF, TAG:VALUE, desire to see all formats side by side.
  • In terms of examples to use, we want something smaller, so selection is important. consider Timezone.js from NPM, file is 200 lines, 150 lines from relationships, 3 dependencies. Other suggestions welcome.
  • Jim suggests we also look into compatibility tests in this area as we go forward. In particular he's interested in seeing some of the lessons from FUZZ testing applied here. He will come back with further proposals in future.