ASWF TAC Meeting - May 20, 2020

Video Conference Link

Voting member attendance

Other Attendees

John Mertic (Linux Foundation)
Emily Olin (Linux Foundation)
JT Nelson (Pasadena Open Source consortium / SoCal Blender group)
Jeff Bradley (Dreamworks)
Luke Emrose
Ashley Whetter, Python 3 Working Group / DNeg
Nick Porcino, ILM
Michael Zink, Warner Bros
Greg Denton, Microsoft Azure
Alex Meddick, Rising Sun Pictures

Apologies

Joshua Minor (OpenTimelineIO)

Agenda

Vote on video recording of TAC calls
- Vote was negative, so won’t be recording TAC calls unless we specifically decide to
- Some follow up as to whether this extends to TSCs: vote only mentioned TAC meeting for now. The TSCs should have the scope to decide for themselves. So the default position would be no recording, but TSCs can decide otherwise.
- Michael: OCIO has never recorded their TSC meetings, will stick with that position.
- Cary: OpenEXR hasn’t recorded their TSC meetings either, sometimes wish could playback through discussion when writing notes after the fact, but there is value to discussions being “off the moment”, may affect the tone if you know what you are saying is being recorded.
- Nick: OTIO frequently has vendors in attendance, who don’t want to take on fiduciary responsibility to commit to features.
- Larry: similar comment, perpetuity of recording has an influence
- John: should make sure that TSC meetings aren’t the right place to discuss features of commercial products, want to make sure not to run into antitrust issues
- Daniel: so default position for TAC and TSCs is no recording, unless a specific TSC wants to override that
Technical Project updates
- OpenEXR
  - IMath separation
  - Cary: Starting with Google Summer of Code intern, set up a weekly check in to touch base. Nature of project is that Owen may “burn through” the project scope fairly quickly, but may also end up running into unforeseen complications. So better to stick to the official timeline with 30hrs/week in early June.
  - Set up a spreadsheet to break down tasks as a lesson in project management, seems to be going well.
  - Got another ping yesterday from the Google autofuzz project, which had approached us last year to add OpenEXR to their regular schedule. At the time we had declined due to concern with the volume of potential reports for obscure bugs. This could be construed as us taking a position on security (not taking it seriously)? We may not have the resources to respond to this in a timely way. Security may be less of a concern for many ASWF projects (running behind the firewall). But some projects such as OpenEXR are part of operating systems.
  - Nick: the 30 day “ticking clock” nature of the system (being put on a “shame list”) would be a problem given project resources.
  - OpenEXR is part of the macOS ImageIO framework, used throughout the OS. A lot of the early security fixes in OpenEXR were based on internal fuzzing by Apple.
  - Would this be an “endless trickle” or a “tsunami” of reports?
  - Gordon: half a person over 1 year for FBX issues that came up when it was included in Windows
  - Cary: “500 cores for 2 weeks” thrown at EXR: the “obvious” stuff might have already been caught, and those issues were already mostly dealt with.
  - Larry: how good are they at accepting “won’t fix / false positive”? Cary: 6 issues were submitted last week that were garbled, issue title didn’t match the stack traces. Issue was caused by using an uninstrumented standard library, which turned out to be a false positive.
  - Daniel: how official is the “won’t fix” process? Nick: Debian had reported a bunch of issues, OpenEXR declined to fix some of those. Cary: what’s to stop the fuzzer from reporting the same issue again?
  - Gordon: there’s a difference between a true “won’t fix” and “this isn’t a real issue”
  - Nick: Would still be preferable to have our own approach. As an organization we should have a set of standards we adopt, but not necessarily comfortable with OpenEXR being “out on its own” with regards to Google fuzzer.
  - Daniel: desire to make this decision carefully that can be generalized across projects, and lack of knowledge about the implications. We could resolve the lack of knowledge issue by signing up OpenEXR, and make it as part of our second stage of CII badge which adds dynamic fuzzing as a requirement.
  - Cary: will follow up with Google to get more information on the process.
  - Daniel: perhaps there’s a different service we could use instead.
  - Cary: these vulnerabilities aren’t just relevant to ASWF and member companies, the issues mostly affect use of OpenEXR outside our community.
  - Gordon: from a tool provider side, need to worry about security issues even in this space, especially given use in the cloud, and investing quite a bit into security.
  - Eric: is there written documentation on the IMath split? Cary: general outline sent to the OpenEXR mailing list. Would be worth publishing on the OpenEXR web site. Follow on is a large modernization of the repo (const_expr, CUDA compatibility…)
  - Daniel: also a useful thread on OpenVDB mailing list about adding Half Float data type to C++ standard
- OpenColorIO
  - Documentation revamp
  - OpenColorIO-Config-ACES repo: meeting with ACES leadership to clarify relationship between OCIO and ACES, issues of licensing. Started new repo OpenColorIO-Config-ACES under ASWF organization, will work in collaboration with ACES, revamping distribution plan for official OCIO configs.
  - Will establish WGs for official OCIO configs, also opportunity for studios to contribute configs to leverage infrastructure being put in place. Daniel: interesting model for not-quite-software distribution. License will be the same BSD 3 Clause than OCIO, there’s typically a Python library included to do things like generate LUTs.
  - Michael: the CI will be dependant on build artifacts, want to make those artifacts available for download.
  - Michael: two new members to TSC, Carol and Sean working on a documentation revamp for V2, need to revamp the content and structure of the documentation, new website as well. Looking at different solutions, reaching out to community for feedback. Also working with Emily to leverage what can be reused from Linux Foundation.
  - GPU build project: Andy from releng still working on infrastructure needed on the lf-releng side, organizing AWS account is a bit complicated, but should have something to report at CI meeting next week.
- OpenShadingLanguage
  - adoption process
  - Still waiting on clarifications about CLA.
  - Larry: last TSC meeting was almost all about technical instead of administrative issues, which is good progress
Working groups
- USD
  - Group has resumed activity. Cory: had a good meeting with good attendance. Discussed stated goals and non-goals, agreed that they were appropriate. Discussed the deliverables.
  - USD Working Group GitHub Repository : deliverables, meeting schedule, meeting notes
  - Daniel: CI working group “spontaneously” created, the USD WG is the first one with a somewhat more formal process. Process was inherited from CNCF, TAC should vote on endorsing the USD working group. Daniel: proposal for WG was merged into TAC repo.
  - Working Group Process Document including endorsement by the TAC
  - Daniel: it may be a bit hurried to vote on this TAC meeting? Otherwise we’ll do a vote by email to keep things moving.
  - Cory: will start doing the announcements on the USD interest mailing list to reach out to a wider audience.
- Diversity & Inclusion
  - Emily working on identifying the right people to move
  - Carol Payne from Netflix and Rachel Rose from ILM will co-chair, had a call last week to discuss plans
  - Will make official proposal to the TAC soon, discuss specifics like term limits, TSC structure…
  - Send overview document to the TAC
- Python 3
  - Henry Vera from DNeg brought Ashley Whetter onto the call, leading internal Python 3 effort at DNeg.
  - Next step will be to have a small number of formation meetings to determine goals / non goals and come back to TAC with proposal
  - Daniel started the process going, handing off to Henry and Ashley
ASWF fund, grants
- Looking to establish a presence in the Linux Foundation Community Bridge system to identify projects of interest to our community and potentially grant funds to support those projects.
- Can we identify projects where funding would help with development?
- Could the original VES Tech Committee document identifying OSS projects in VFX be used as a source?
- Daniel: typically an existing project will identify a need for a key developer, and use Community Bridge to seek support for that developer. Second approach would be more open ended, for instance articulating needs for remote review, and seeing whether this mechanism could be used to get to a solution.
- Is this similar to the “Google Summer of Code”? Could we look at funding some of the students ourselves?
- Daniel: does the TAC think this is a valid mechanism for the goals of the TAC / ASWF, and also look at the at the specifics.
- John: can share experience from other foundations. Somewhat wider scope than GSoC, lots of models of how it could be used. David had talked about establishing a fund / grant program, but there are other options as well.
- Daniel: we probably need more time / offline discussion, will work with John to work out specific examples.
Vote on USD working group
- JF is moving to endorse USD WG
- Daniel seconds
- All Yeah, no abstain or reject
- Adopted unanimously, first officially endorsed WG
Update on candidate projects
Next meeting: 3 June 2020

ASWF TAC Meeting - May 20, 2020

Voting member attendance

Other Attendees

Apologies

Agenda

Action Items (AIs)

Notes

Chat