Daniel Heckenberg - Chairperson, Animal Logic Pty Ltd
Gordon Bradley, Autodesk
Mark McGuire, Blue Sky Studios, Inc.
Michael O’Gorman, Cisco Systems Inc.
Henry Vera, Double Negative
Bill Ballew, DreamWorks
Matt Kuhlenschmidt, Epic Games, Inc.
Brian Cipriano, Google
Jim Jeffers, Intel Corporation
Larry Gritz, Sony Pictures Imageworks
Jean-Francois Panisset, VES Technology Committee
Cory Omand, The Walt Disney Studios
Kimball Thurston, Weta Digital Limited
Ken Museth, OpenVDB Representative
Michael Dolan, OpenColorIO Representative
Cary Philips, OpenEXR Representative
Eric Enderton, NVIDIA
Apologies
Other Attendees
David Wheeler (IDA)
John Mertic (LF)
Andrew Grimberg (LF)
Greg Gewickey (WB)
Emily Olin (LF)
Mark Elendt (SideFX)
Patrick Hodoul (Autodesk)
Kevin Wheatley (Framestore)
Cary (Cisco)
Robert Vinluan (SideFX)
Agenda
Goals for TAC: Year 1
Timeline:
May: CI platform decision (based on at least one example setup)
CircleCI, Azure Pipelines
OpenColorIO potential candidate for integration
June: CII badge. At least one project graduation.
Expectations
Filters for analysis / scan shared across projects
Accelerate project graduation
July: Dependency management.
In context of our CI system first
Broader community scope
CII Best Practices Badge discussion (David Wheeler)
Analysis requirements, how to interpret fairly open ended requirements and how to address them
Many tools used by other LF projects not applicable to our C++ projects
Key requirement is project must use a static analysis tool: cppcheck for instance. There are suggestions to use tools that specifically check for security issues (not required).
Dynamic tool requirement is a suggestion, it is encouraged but is not a requirement.
Most tools provide some kind of guidance document about what should be turned on and off, apply common sense to avoid “busy work”
Use comment strings in code to disable specific scanner warnings
No specific requirements on the testing
Main idea is to have “something you can improve on”, start with weak rules, improve over time.
No specific requirements for testing, except:
You must have automated testing in place
You must add new tests to cover new functionality
Different between green field and brown field, existing projects will typically have huge amounts of warnings
OpenColorIO
Analysis and security are areas where they have yet to make much headway
How to deal with legacy code that has less test coverage vs new code that has good coverage: is it mandatory to go back to improve coverage of old code? David: there are 3 badge levels, “Passing / Silver / Gold”, focussing more on getting projects to “Passing” first. No strict coverage requirements for “Passing” level, there’s a “suggested” requirement for dynamic analysis. Vary the inputs / 80% coverage. For “Silver” you require 80% test coverage, of course possible to have high coverage yet a lousy test suite. Mike: OCIO has a “legacy” branch in current use, and mostly new code for the new version, so probably won’t go back and invest a lot of time in adding coverage to that old branch. David: focus at the project level, but expected that the idea is mostly “going forward”. So 80% coverage would be for the active development branch. Mike: future branch for release in 1 year or so. David: most of their projects release at a faster pace, so could target “passing” for now, “silver” for next major release.
CI updates
(Andrew) Updates from LF
Azure pipelines still most promising candidate (3 platform, GPU support and cost)
Working group
Technical Project updates
OpenVDB
Andrew: stale branch cleanup.
OpenColorIO
Azure test project
Michael: Setup for Linux builds. “Task” structure seems to work well. Using conda for dependencies as it’s built-in. IDE on AzureDevOps for fast iteration.
Next steps: Sonar Cloud.
CII badge progress
Blocker is still embedded dependencies
This is a candidate for other engineering resources to contribute. Mostly CI / CMake support to gather dependencies for simple download and build workflows.
Have marked “Good first issue” etc for GitHub issues
Action item: Visible ASWF-level list of contribution opportunities (e.g. project issues) via aswf.io wiki or Github?
OpenEXR
Cary: Use of JIRA for both project administration and software development? OpenVDB is using ASWF JIRA instance here.
Cary: Mailing list transfer to aswf.io. Any use for separate -user, -dev, -announce lists?
Andrew: Historically projects started with separate lists, but now have a single list and use hashtags for filtering
John: Can merge list and archives (after spam removal)
Cary: CII best practices badge. Github provides good basis for many criteria. Project website needs to be updated and modernised from hand-rolled HTML.
Andrew: Github pages is recommended. LF Releng uses ReadTheDocs for its docs.