Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add REUSE license checker and CI check to new glTF 2.0 branch #2029

Merged
merged 5 commits into from
Sep 23, 2021

Conversation

oddhack
Copy link
Contributor

@oddhack oddhack commented Sep 22, 2021

  • Replaces old specification/2.0/README.md which contained the 2.0 specification document with a link to the new glTF Registry which will contain generated HTML / PDF outputs from the asciidoc version.
  • Add license text of all licenses used under LICENSES/.
  • Add copyright statements that are readable by REUSE where reasonably possible.
  • Add .reuse/dep5 entry as fallback licenses for images etc. where explicit copyrights not possible.
  • Add 'reuse lint' check to github Actions CI
  • Use 'TBD' license on vendor extensions, none of which seem to have explicit licenses and may not be owned by Khronos.
  • Some minor whitespace / EOL convention changes.
  • Add boilerplate files missing from repo such as CONTRIBUTING and COPYING.

* Add license text of all licenses used under LICENSES/.
* Add copyright statements that are readable by REUSE where reasonably possible.
* Add .reuse/dep5 entry as fallback licenses for images etc. where explicit copyrights not possible.
* Add 'reuse lint' check to github Actions CI
* Use 'TBD' license on vendor extensions, none of which seem to have explicit licenses and may not be owned by Khronos.
* Some minor whitespace / EOL convention changes.
* Add boilerplate files missing from repo such as CONTRIBUTING and COPYING.
COPYING.adoc Outdated Show resolved Hide resolved
@emackey
Copy link
Member

emackey commented Sep 22, 2021

The replacement content in specification/2.0/README.md uses <p> tags that defeat the Markdown:

https://github.com/KhronosGroup/glTF/blob/baac23072ebb7f24ab98b8f0279211f638816720/specification/2.0/README.md

@emackey
Copy link
Member

emackey commented Sep 22, 2021

This looks good to me. Some questions:

  • Is it possible to put a message that is visible at the top of GitHub's preview of Specification.adoc, but which does not appear in the final rendered HTML & PDF? It would be great to post a warning that users are perusing an incomplete picture of the doc when they're looking at the GitHub preview, and point them at the rendered copies instead.

  • I wonder if the vendor extensions belong in vendor repos, not the Khronos repo? Lots of folks submit vendor extension PRs, but we have no one who can review or maintain a vendor's own proprietary schema. This is probably a question for @lexaknyazev and/or the WG itself I guess, but I'm starting to wonder if Khronos should only host EXT and KHR extensions, along with links to external vendor repos that are known to have their own extensions hosted.

@lexaknyazev
Copy link
Member

@oddhack
Should we merge this PR into jon-adoc before merging #1901?

@oddhack
Copy link
Contributor Author

oddhack commented Sep 23, 2021

@oddhack
Should we merge this PR into jon-adoc before merging #1901?

Yes, if the WG is comfortable with that. If not, it can be retargeted to the default branch after jon-adoc is merged.

@oddhack
Copy link
Contributor Author

oddhack commented Sep 23, 2021

  • Is it possible to put a message that is visible at the top of GitHub's preview of Specification.adoc, but which does not appear in the final rendered HTML & PDF?

Easiest way would be to define an attribute in the Makefile and use asciidoc ifndef::attribute[] to delimit github-only text.

  • I wonder if the vendor extensions belong in vendor repos, not the Khronos repo?

For most of our APIs we've felt there's considerable value in having a single place to look for extensions, but YMMV of course.

README.md Outdated Show resolved Hide resolved
@neiltrevett
Copy link
Collaborator

neiltrevett commented Sep 23, 2021 via email

@lexaknyazev
Copy link
Member

@oddhack
How difficult would it be to add a timestamp (and maybe a commit hash) to the rendered docs?

@oddhack
Copy link
Contributor Author

oddhack commented Sep 23, 2021

@oddhack
How difficult would it be to add a timestamp (and maybe a commit hash) to the rendered docs?

It's not difficult in the PDF/HTML builds. See definition of SPECDATE / attribute revdate and SPECREMARK / attribute revremark in https://github.com/KhronosGroup/Vulkan-Docs/blob/129f6f69dcbc00184d771d2da969b4ed394ac80c/Makefile#L135-L162 and corresponding https://docs.asciidoctor.org/asciidoc/latest/document/revision-attribute-entries/ . With the proper document header setup the specified {revdate} and {revremark} attributes will get passed through to the output docs in the title section.

@lexaknyazev lexaknyazev merged commit 5d3dfa4 into jon-adoc Sep 23, 2021
@lexaknyazev lexaknyazev deleted the reuse-adoc branch September 23, 2021 08:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants