ASWF TAC Meeting - March 24, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, Linux Foundation
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Mathieu Mazerolle, Foundry
Alex Meddick, Rising Sun Pictures
Carol Payne, Netflix, ASWF D&I WG
Sergio Rojas, Arena World
Rachel Rose, ILM, ASWF D&I WG
Scott Wilson, Rust WG
Van Bedient, Adobe
Darby Johnson, DJV
Patrick Hodoul, Autodesk / OCIO
Scott Wilson, Rust WG
Mac Moore
Alex Forsythe, ACES

Apologies

Agenda

Notable Events
- Open / Imath EXR 3.0 beta release (Cary)
- Official release on April 1st
- Links on mailing lists
- Pretty quiet / not much feedback, hopefully good news?
- John: how long since OpenEXR 2.0? Kimball: 2012, so 10 years
- A big reorganization
Open Cue Graduation Proposal (Brian)
Open Source Forum Recap and discussion (Kimball / John)
- 85 registrations, 55 attending, recordings on YouTube
- ASWF Open Source Forum 2021 Poll Results
- Attendee survey, not a lot of response (please complete if you attended)
- State of the Union was well received.
- Missing aspect of networking within virtual events, every community / event continues to struggle with this. Some interesting concepts, have been looking at some options. Maybe to be addressed for Open Source Days this summer. Would make sense for a smaller event geared towards networking.
- Kimball: no one said it was “a waste of time”, all projects and wgs were well received. “We’re talking about the right kind of things”
- Morning half was more attended than afternoon.
- Poll: USD / MaterialX are at the top of list that should be onboarded, but surprising third place was “linux distro”
- Seemed like there was some confusion from attendees as to whether MaterialX was open source or not (it is)
- Should we start a working group on a Linux distro? Daniel: this has been an issue for the VFX Platform, this is motivated by the end of “traditional” CentOS which was unofficially the basis for the VFX Platform? Kimball: should we even be looking into this is the first question. Could we benefit as an industry to have our own Wayland server so we have better access to the GPU for direct rendering? Wave: a Docker container with all the prerequisites is already a struggle, a full Linux distro is an order of magnitude (or two) more complexity. Kimball: we wouldn’t try to do it ourselves, like the Arch Linux distro, but they have rolling releases as well. But we could define a snapshot of that? Larry: even with a snapshot, the work to follow the 1000s of packages would be huge, security updates… John: conversation about Desktop Linux, are upstream contributions part of the discussion, or just “assembling a distro”? Kimball: there is a Linux version of Unreal, it runs, but the Unreal editor doesn’t work very well compared to Windows for instance, would Unreal on Linux be helped with better low level access to GPU? Alex F: is the objective to create a Linux distro for the motion picture industry, or just provide a common set of package versions for ASWF projects? Daniel: people really want the “out of the box” workstation setup experience from CentOS, long term support via the RedHat upstream, security fixes, erroring on the side of long term stability while still able for third party vendors to push updates. CI is somewhat of a “solved” problem on Linux with containers, but not necessary for runtime on workstations (some experimental work at Animal Logic, Dreamworks). But this builds on top of CentOS distros. Alex F: so an effort to replace what goes away with Centos. Scott W: a big challenge for pipeline TDs has been updating things like OIIO, trying to get all packages happy with specific version of Maya, Nuke Houdini, if we were to look at making a Linux distro, would want to be able to “yum install oiio-python”, that would be hugely helpful, but a hard problem to solve. Kimball: received email from Nick Cannon from VES Reference Platform to preset at next TAC meeting, need to take legacy VFX Platform into consideration. HPC industry is in the same boat. John: LF has a project in the HPC space. Scientific Linux merged into CentOS many years ago. Similar industries are in the same situation. JF: also don’t want to stray too far from what storage, networking vendors support. Daniel: parallel available of different versions of DSOs has long been an issue, vendors distribute their own libraries to make their apps self contained, but hinders build systems. Brings us to domain specific package management system. A separate discussion about “how do we contribute to Linux to make it a better platform for our use cases”, and that’s been a sorely neglected area. We haven’t contributed much, apart from a few patches to Qt for instance. For instance Wayland improvement, better support for color management, HDR on the desktop… Eric: vendors like NVIDIA may not be enthusiastic about supporting a wildly different kernel / distro. Mark V: installing any new software came with requirements for specific NVIDIA driver versions, specific package / library versions (compat-XXX). Having the stable base that everyone can target, and an official “film repo” that has all these compatibility packages would be better than the “tribal knowledge” of how to make this all work.
- Joshua: should we have some representation on one of the other distro efforts?
- Kimball: Ubuntu is a viable alternative. Should the Reference Platform consider basing itself on Ubuntu LTS?
- Daniel: is that the best answer, can we push this back to the VFX Reference Platform? Addressing the change of status of CentOS is a critical issue. ASWF could ask as a funnel to contribute info back to Reference Platform. Kimball: Reference Platform to present at next TAC meeting.
- Kimball: quick poll:
  - Should we start a WG on Linux Distro
    - Consensus seems to be we shouldn’t try to create a Linux distro.
  - Should we start a WG on package management
    - Daniel: this has been in the realm of the CI WG so far, should we encourage people to be involved in current efforts, vs starting a new effort? Larry: CI WG has not just been about CI for a long time, it has grown to encompass other software engineering issues such as package management.
    - Kimball: don’t necessarily want to add another working group, but may want to refocus the CI WG to focus on a package repository?
WG Reviews
- Kimball: we should review the status of our Working Groups
- Should also review the projects
- Every few meetings we should pick a WG (or a project) and discuss in greater depth. Also decide at what point we should close off a WG and reorient efforts if needed.
- Does this sound like a good idea?
- Brian: yes, this sounds good. Eric: is OK with quick updates we’ve been doing.
- Eric: WG leadership would need time to prepare for this.
- Next meeting we could do a deep dive on OpenCue since they just submitted their graduation. Good to revisit.
- Daniel: WG charter is that some WGs are supposed to produce specific outputs in a specific timeframe. WGs shouldn’t necessarily live forever.
Asset WG (Wave)
- Looking at a “minimal” license we can offer to people who want to donate an asset, it is on the Wiki. Asking for comments, bring the license to your company’s lawyers, and see if that would work for your organization if you wanted to donate an asset.
- Also important: would this license allow you to use an asset that falls under this license. The license has to work both way: donation and consumption.
- ASWF Asset Repo Draft License
- Also picking an existing license vs making a new one
- Eric: want to be able to benchmarks / marketing with an asset, but not “make a movie” with the asset. Moana used the BSD 4 clause and added those restrictions, broadened that for the asset repo.
- John: could be interesting to run this by legal committee. Wave: yes, please follow up directly. Would be great to “not introduce another open source license”, but there may be reasons to.
- Daniel: Creative Commons style licenses are probably most suitable here, under Australian copyright law, there are specific, different rights for assets. This kind of specificity seems like what we are looking for here, rather than in the software license world. Wave: “we are not lawyers”, and “all of us have lawyers”, so shopping around the Moana license to our company lawyers seemed like the fastest way to go there, but could also pick the “closest” CC license. Joshua: most CC licenses specifically require attribution, but for instance the Moana license explicitly says you can’t attribute to Disney. Also the term “non commercial” is vague. Eric: we want the assets to be usable commercially. Joshua: a lot of the existing assets have “no commercial use” restrictions. Larry: suggested license is a very small edit on the Moana license, has been accepted by a lot of our companies already, and it came from Disney which typically has some of the most stringent requirements. Even an established license from the outside world may be new to our respective companies.
Slack crisis (Larry)
- 10K limit on messages is being a real issue
- At beginning of Feb, the 10K “deletion” horizon was August, deletion horizon is now January. Seems like there’s a lot of traffic is DMs, but also a lot of traffic that doesn’t really have to do with our projects.
- We should move the non-project to a different Slack instance, pick another platform, or pay for a paid instance.
- We should associate a cost. Carol: we need to be careful about the separation of conversations if our goal is inclusion.
- John: LF is putting a Slack alternative based on Matrix, looking to do a POC, have been pinging the team, could ASWF be on this Matrix PoC? No new charge to the project, would be covered by “IT Services Provided”. The issue with paying for Slack is that it’s a variable cost, the more successful you are, the more expensive it gets.
- Wave: running yet another chat client is an issue
- Alex F: looked at same issue on ACES, the open ended pay structure made it a non starter. Ended up using Rocket Chat, has pros and cons, but have fixed costs.
TAC guidance on VFX Platform sunset dates, etc. (Larry)
- Let’s make sure to address this at the next TAC if Reference Platform is presenting, every project wants to know how many years they should support. Also things not in Reference Platform we would want to address. Daniel: should we present survey results that are related to this issue, and present those results to Reference Platform? Larry: looking at survey result, the results seemed ambiguous. Was hoping to see a consensus as to whether people wanted support for previous years or not. Trying to reduce the build matrix. Could be pushed back to the CI WG, since they are at front and center of grappling with this problem (should be renamed the “everything build related” group?).
- Daniel: people will stick with what they are doing until they are forced otherwise. Picking a number (“we support 3 versions back”) and see how much pushback could be a valid approach. Kimball: how far back do we have to backport security issues is a driver. Larry: these are two separate questions. For instance with OpenEXR, there are 2 overlapping but separate problems. How many versions back of OpenEXR do we support (especially for security problems), and how many years back of Reference Platform should we keep the current version of OpenEXR to support building? Kimball: if a year of Reference Platform specifies OpenEXR 2.4, should we care if you can build OpenEXR 3 in that environment? More cross-project guidance in this project would be important.