AWSF TAC Meeting - February 07, 2019

In person meeting as part of the Open Source Forum at the Academy of Motion Picture Arts and Sciences, Beverly Hills, CA.

Voting member attendance

Checkin on goals and progress

2 projects are now officially in the ASWF from goal of 6 projects, OpenEXR looking positive for February, which leaves 3 open slots.

CI Infrastructure: we have hit decision point on how to manage our dependencies, refer to TAC mailing list, survey of systems by Aloys Baillet (A). Build & Test for DCC plugins, OpenColorIO will be a good opportunity to exercise dependency management on Maya, Nuke. Work happening behind the scenes to deal with legal / licensing issues. We are working on meeting the requirements for CII Badge, especially static analysis.

Stretch Goals for remainder of the year

Downloadable artifacts
Windows Mac, GPU builds

Update from Board Meeting

Presented by David Morin from ASWF

Board meeting happened in the morning, OpenColorIO was welcomed officially into the ASWF. Discussions focussed on summary of first 6 months, ASWF reached most of its goals so far, OpenEXR is close to submission in the next few weeks. Looking at the future, new projects targeted for future inclusion, specifically what types of projects to target.

New members: NVIDIA, present at first board meeting.

Eric Enderton from NVIDIA is new TAC member. Director of Film Rendering Technology at NVIDIA. Originally worked with Larry Gritz on Gelato project. They are interested in helping people use GPUs as much as possible.

Update from OpenVDB

Transfer of CI infrastructure from Travis to ASWF Jenkins, address issues encountered by developers used to previous system
Need for GPU, Houdini for some parts of the build
Need assistance with CMake expertise (project was using make), they can reach out to others via the TAC, overlaps with project to create reusable CMake components
Question about role of GNU autotools going forward, OpenEXR was maintaining both, which is a major hassle. Daniel: we will settle on CMake as the industry standard tool especially given multi-platform requirements. Larry Gritz: wide consensus on CMake between OSS projects, feels autotools are “on their way out”, very little expertise. “CMake is the least evil system available”

Update from OpenColorIO

Changes to the CLA (Contributor License Agreement): Larry Gritz, after getting all clearances from Sony legal (based on OpenVDB CLAs), but last minute change after vote was taken, may need a re-vote to switch to simplified CLA (provided by Linux Foundation). CLA updates
Linux Foundation: Once a project is established, the project can “self govern” via its own TAC
Larry: Sony legal team like LF CCLA template better than the OpenVDB one which relies on some definitions in the Mozilla license which isn’t used in OpenColorIO. ICLA template didn’t include some required definitions.
Doug Walker (Autodesk): moving along with OCIO v2 pull requests, will have another video conference meeting in 2 weeks (after HPA) to discuss most recent pull requests.

Update from CI Working Group

Ongoing discussion on dependency management options, both for CI builds but also wider problems in studios
lLst meeting joined by Allan Johns maintainer of Rez project, also discuss whether Rez belongs as a ASWF project
clang-tidy would be a sufficient tool for CII badge compliance, can integrate variety of external tools (including free for open source commercial tools)
Requirement for a security expert for CII badge, Intel (James Jeffers) offered some security expertise support
Should designated ecurity experts operate within individual projects, or operate at a higher (ASWF) level
Ken Museth (OpenVDB): Ken feels it would be good to share expertise between projects. Guidelines are very vague, so we need to agree on specific goals. James (Intel): can also help defining security goals and processes, not just actual development support. Intel has “Security Champions” who could contribute. Gordon Bradley (Autodesk) has similarly “Security Champions”: Autodesk feels the idea of every project have a security expert is unrealistic. Project-specific “Security Champions” can consult with company-wide security experts, deal with handling of specific security issues. Intel agrees with that model. Gordon: 90% of your issues are in external libraries, not your own code, how do you address issues in external libraries.
Daniel: OpenEXR has 12 reported CVEs, so that’s an example
Ken: EXR, VDB are exchange formats which support encoding metadata, so can be vectors for malware.
James: will need some kind of signing process for build artefacts.
Gordon: trying to bullet proof a file format has lots of implications (performance, development effort…), we need to be pragmatic with our investments. May need to define the scope of what we are trying to address.
Larry: may not be able to “hide behind” the idea that studios work behind firewalls: ASWF may cause our projects to gain wider adoption, outside of our restricted environments
Daniel: Apple offered to help with fuzzing
John Mertic (LF) DCO and signing of past commits: git log for past commits, add those to text file, sign off that log of your past commits with DCO. Do you need to chase down all former committers? If all committers are from one company, can nominate a person to sign off all commits from that company. For external contributors, would be good to try to chase them down, or use CLA if there’s automatic assignment. Are there tools to report on DCO coverage of a project? There’s a Ruby command line tool, documented in ASWF documents. Does this need to be done before a project joins the ASWF? For new commits there’s a “DCO Bot” that prevents unsigned commits. LF does a “license scan” of existing code before a project is onboarded (to make sure project is consistently licensed), could add DCO scanning.
Gordon (Autodesk): if one of the goals is to help onboarding projects, how to we make things easier for new projects, and not throw up barriers. How can the ASWF help? We have access to some funding, could pro-actively scan potential projects?
John (LF): they try to highlight potential problems, but different companies may do things differently. For instance handling of copyright statements. LF tries to make license compliance as easy as possible for developers, LF can take care of the “ugly problems”, but they cannot give legal advice. LF does have forums for member legal teams to discuss / collaborate.
Kimball: there is a one line git command to find commits not signed with DCO
Larry: we should have a “best practices guide” aimed at potentials projects / prior to applying / creating new projects from scratch (always easier to do at start).
John (LF): we need to document what we are learning, every open source project is slightly different

Motion: accept the PR from John at LF for instructions / guidelines requirements for CDOs on past commits

Daniel moves.
No opposes, no abstains

Open discussion: candidate / future projects, any other topics

Standardized Versioning Scheme*
- Guido (Pixar): discussion on standardized versioning scheme. When a project gets onboarded should we reset the versioning scheme to pick a consistent scheme, best to do now if we are going to do it.
- Kimbal: needs to be tied to VFX Reference Platform, which is tied to our CI infrastructure.
- Gordon (Autodesk): how do you deal with coupling in revision updates between VFX Reference Platform and individual components. He really likes the idea of a consistent versioning scheme. Also hits the goal of providing a “platform” for new projects.
- Ken (OpenVDB): doesn’t like the idea of resetting existing versioning numbers.
- Daniel: what is the proliferation at this stage? How many models, for instance USD (YYYY.MM), Linux creates specific scheme (X.Y.Z).
- Guido: what does X.Y.Z even mean? Could at least make sure to define what those numbers mean.
- John (LF): could align with semantic versioning scheme. This is a part of dependency management, should be not contentious and there’s a chance to fix a “low hanging fruit”.
- Daniel: start with semantic versioning.
- Ken: OpenVDB is slightly deviating from semantic versioning, they only apply that to the data structure, so change in minor version guarantees backward compatibility for the data files but not the tools. Similar for ACES, sometimes unclear where changes fit within that versioning system.
- John (LF): largest issue is API compatibility.
- Ken: also care about ABI compatibility.
Project Test Data
- Guido (Pixar): how to deal with test data that goes with projects / test suites. There should be a mechanism to include test data in actual libraries for testing and validation, should that be a pre-requisite for acceptance?
- Larry: this is a requirement for CII badge.
- John (LF): this can be part of the incubation phase. Projects can skip incubation phase if it feels it meets all requirements.
Brian Cipriano (Google): OpenCue project proposal is coming soon.
Daniel: How do we get the work for Mac / Windows done.
- Some initial work on Windows from LF Release Engineering team to provide a platform, but need sufficient motivation to start moving builds and tests on Windows, OpenColorIO is very motivated to do so. Should we look for expertise elsewhere?
- Doug Walker (autodesk): need help from Linux Foundation to help get infrastructure set up, interface with LF RelEng.
- Gordon: they have some Windows expertise, but they would like to keep it on the actual OpenColorIO project, would rather see infrastructure come from LF Infrastructure.
- Larry: do any of the member companies have resources?
- Matt (Epic): Windows is their primary platform, they will see if they have resources available.
- Thanh (LF): happy to join any calls to help getting up Windows infrastructure running. Also Apple is soon to (hopefully) join the ASWF so would be able to help with Mac builds.
- James (Intel): OSPRay uses CMake to support all platforms, they make it a point to support all platforms, could this be a model to follow?
- Daniel: We also need feedback from Windows / Mac people in studios to ask if support is usable.
- Liam Fernandez (Blur Studio): they are mostly Windows based, very interested in helping with Windows build infrastructure. They have also struggled with semantic versioning.
- Guido: surprised that Windows CI infrastructure didn’t come from LF?
- John (LF): the infrastructure they provide should be configurable by the individual foundations.
- Thanh (LF): he’s here to help, the community is there to “lead the charge”. If there are resources LF is not providing, he can go back to see if that can be addressed.
- Larry (Sony): foundational projects have a current set of maintainers are Linux centric, need to bring in outside people who can help.
- Daniel: we need to take advantage of the offers of support to help with outstanding issues.

Conclusion

Daniel: there is a lot of positive feeling about the work that’s been done by the TAC, thank you all!