ASWF TAC Meeting - October 7, 2020

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Ashley Whetter, Python 3 Working Group / DNeg
Carol Payne, Netflix, Diversity+Inclusion WG
Sean Wallitsch, DreamWorks
Nick Porcino, Pixar
Patrick Hodoul / Autodesk / OCIO

Apologies

Michael B. Johnson, Apple

Agenda

Goals for TAC: Year 2
OpenCue Packaging and deployment (Brian)
- How to package Python and all dependencies into a single, installable binaries.
- Discussing with John: potential issues with licensing of binary distribution? If OpenCue handles this at the project level, would likely opt to not distribute binaries, instead make it easy to build installers by the users themselves. Not ideal, but less complicated from a legal perspective.
- Would be better to do this at the ASWF level rather than at the individual project level.
- John: IANAL, but the gist is that there are different considerations to distributing binaries instead of source for an open source project, implications with patents and encryption. Not impossible, but extra work required. Some project communities go down that path, can implement export controls for instance. Most projects leave that as “downstream” activities to be handled by end user, vendor or Linux distribution packager.
- Docker is a whole other can of worms, LF has a blog post from April 2020 on the topic. Daniel: where’s the line between artifacts, containers, and other forms of binary distributions.
- John: many “unknown unknowns” in terms of licensing.
- Daniel: LF can provide some experience from other projects, but we need to take this “journey” on our own. Makes sense for OpenCue not to want to do this on their own.
- John: LF is more than happy to help provide guidance, and may require some degree of assistance from LF (export control infrastructure for instance for encryption).
- ASWF is a larger legal target, so need to be careful. Want to make sure that assets distributed downstream are as “clean” as possible from an IP perspective. LF has projects that do binary distributions, but many projects decide not to.
- Also can increase the support burden: users will expect that a provided binary gets supported. Often downstream vendors willing to take on support burden rather than the projects.
- Daniel: one way to try to sidestep as many “unintended dependencies” is not to provide a “single, all inclusive” download, but instead work within an existing component manager where the other dependencies come from somewhere else. John: also good if you integrate into those ecosystems.
- John: if a distribution is a Python package, which is a collection of Python scripts, so in fact you are distributing “source code” (say via Pip). So it can often be a case by case decision, likely no “one size fits all”.
- Daniel: OTIO is another group talking about distributions in the context of Python. Josh: OTIO is a hybrid model, Python package via Pip, but also a C++ core, so providing Python Wheels to include pre-compiled versions of the core library. Would be helpful to get guidance as to the implications, what does OTIO need to pay attention to. All the compiled code is OTIO code , any external dependencies have been copied into the repo, rather than having implicit dependencies on a large number of external projects. This is a useful discussion for OTIO, hadn’t considered yet the implications, was mostly providing binaries as a convenience to users.
- John: if any of the projects want to go down this path, can bring in Steve Winslow for some legal help, has helped with some projects before. Projects can reach out to John directly.
- Daniel: immediate need from OTIO / OpenCue, so these projects can help to break some ground.
Follow ups
TAC chair term / voting
- Brief discussion to formalize terms around TAC chair position. Overall feeling seems to be that it would be a good idea to have a process in place. Work with voting TAC members and John, we will vote on these changes as the TAC, and then use those mechanisms to call for a vote of the TAC to vote for a leader.
- Larry: this is the 2nd anniversary, last year we had a vote, but it was informal. John: all our projects have different term limits, election last time had Daniel elected through the end of 2020, so we have some time. Ties into TAC membership renewal. Some communities decide to have these elections in December or Early January, at that point there’s a clearer picture of whether there will be membership changes that affect the TAC.
- Larry: are the company membership tied to calendar years? John: yes. Eric: are there terms on Governing Board? John: no, except for general members and TAC leader. There is a position like the Treasurer, which has no explicit term limit.
Recommendation for VFX Platform Long-Term Support
- Daniel: Try to capture majority of use cases.
- Survey on Project and Platform usage to drive with data, also capture what our projects are doing right now, but draw data input from our user base, what versions are they using, and what are their expectations.
- Also not just versions, but how are they using our projects (request from multiple projects).
- Question of the Python 3 upgrade window, that will stretch from this year into following years, that’s going to cause some tension / pressure. Python 3 support / requirement also helps to sunset older versions.
- If anyone has interest / experience in this kind of survey, would be useful to have input. Also any analogies from other industries / foundations.
- Larry: not sure how to add this to the survey, but issue of which VFX Platform year to continue supporting is important, but there may be other axis we may want to provide guidance, such as CMake versions, which are outside the scope of the Reference Platform.
- Daniel: interesting list of compatibility and interoperability aspects that our projects are using, for instance API compatibility, binary data format. OpenVDB is doing some interesting work, such as ABI symbol versioning to allow swapping the version of OpenVDB which is shipped with commercial applications. Do other projects feel that this is relevant / useful? Or is this niche for OpenVDB.
- Kimball: worth discussing for sure, one approach with customizable namespaces, we can change the API if we want to by putting it in a different namespace, so two versions can live side by side in separate DSOs and namespaces. Replacing a version shipped with a DCC could be very interesting.
- Daniel: best practices for making isolatable dependencies fall outside the scope of the Reference Platform, but we could take on.
Vote: Policy to use non-paid Slack with guidance to move important discussions / decisions to other formats
- Daniel / John: how should this be phrased? John, not sure it needs to be formal? “TAC recommends to continue using the non-paid Slack, with guidance to move useful topics into other forums”.
- Seconded by Kimball
- All ayes, no nays / abstains, adopted
Document security best-practices
- Capture what we’ve learned from other projects, translate somewhat loose terminology from the CII badge approach to specific recommendations for current / new projects. Need a couple of individuals to take this on for the projects they have been involved with. Onus was tilting towards OpenEXR to take the first step (from previous discussions).
- Cary: OpenEXR has been exposed to the issue more than anyone else since official CVEs were reported. Settled at a place where OpenEXR knows what to do to handle these, could write up a summary of what the process is, which could be useful for other projects. Daniel: yes, this would be very useful.
- Cary: ASWF is not pushing on security as a primary concern, keeping our house in order is important, but no one in ASWF has demanded proactive action.
- John: LF launched Open Source Security Foundation which may have some relevant info that could be applicable to our projects. Project is intended to bring a lot of expertise into a single place.
Kickoff: Assets Repository Working Group
- Quick discussion at the end of the last meeting
- Kick off happened earlier this week.
- Eric: broad agreement that this is an interesting area, 16-17 people showed up at kickoff meeting from studios and vendors.
- What does it mean? First project is to identify high level goals. Servicing goals of individual projects with datasets for testing and conformance.
- But also for R&D, make problems visible to the outside world.
- Difference between scenes that are really used in production, with lots of cruft, substandard data, vs a cleaner / more portable dataset. Do we want “best practice” / maintained assets, or a snapshot of “real world” assets.
- Assets can also be used for onboarding / mentoring students.
- Hard to get assets out of studios, Moana Island scene was a success by Nick Cannon, try to remove hurdles of licensing, where is it hosted. Identify what sorts of assets would be most useful, and come up with a small set.
- Meeting again in 2 weeks, Wave will lead the group. Homework exercise: look around your company and identify what could make a good asset to donate to such a repo. Working Group does not aim to build such a repo right now, but first identify what makes sense to have in such a repo.
- Michael Min: git is typically not good to hold this kind of data, are we referring to an actual GitHub repo? Eric: no, just a generic idea.
- Josh: frame.io volunteered to hold such a repo for editorial data. Would need to make sure this is OK with ASWF, as well as long term survival of such a repo.
Kickoff: Media Review
- Happening tomorrow
Hacktober feedback
- Do we have projects that are tagged? Daniel: no, we have some “first issues” tags, but no explicit Hacktober tags.
- Did we get any of the traffic from the early onslaught? Larry: haven’t seen anything in the repos I’m involved. Cory: nothing in the USD repos. Brian: got 4-5 spam PRs, all docs changes, nothing to main repo.
- Daniel: could be handled at project by project level.
Working Groups
- CI
  - No CI working group meeting since last TAC meeting
- Diversity & Inclusion
  - Carol: working with Rachel and Emily, research meetings with some universities, met with ACM D&I group to look at webinars, starting to create an intro to ASWF slide deck. Next meeting is next week.
- Python 3
  - Ashley: not a ton of updates. Last meeting covered Python 2.7 support going forward, and what that means to the VFX Reference Platform. Group agreed that not extending Python 2.7 support officially makes sense, will make things harder for some studios, but need to prod the transition along.
  - Autodesk has provided an official statement on how much longer they intend to support Python 2, hoping to get the other DCC vendors to also provide such statements.
  - https://vfxpy.com visualizes the spreadsheet capturing the state of the migration
- USD
  - Cory: spent last session extending discussion on role of USD in VFX Platform, help to pick a version that works with a VFX Platform year.
  - Discussion on ABI stability, and how integrators can avoid some of the issues coming with fast pace of change in USD.
  - A “universal bridge”, shim that sits on top of USD that could help integrators deal with ABI changes.
  - No concrete proposals yet, but may form a smaller group to discuss offline and come back with a proposal.
Technical Project updates
Update on candidate projects
Next meeting: 21 October

ASWF TAC Meeting - October 7, 2020

Voting member attendance

Other Attendees

Apologies

Agenda

Action Items (AIs)

Notes

Chat