Academy Software Foundation - Technical Advisory Council (TAC) Meeting - March 20, 2024

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language (OSL) Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Academy Software Foundation
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Tom Slanda - The Linux Foundation
Yarille Ortiz - The Linux Foundation
Andrew Grimberg - Linux Foundation Release Engineering

Other Attendees

JT , Pasadena Open Source consortium / SoCal Blender group
Bill Ballew, Dreamworks
Holden Allan
Jeffrey Clark “Alex” - Pillow Project
Doug Walker - Autodesk / OCIO
Jessica Wang

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Agenda

General Updates
- FMX 2024 Open Source Track #595
- Project Proposal - OpenQMC #434
- Security Threat model analysis for ASWF projects #615
New Project Proposal - Pillow #631
Working Group for Rust Bindings #489

Meeting Notes

Do we need the JIRA instance anymore?
- it doesn’t seem to be used anymore
- does anyone have an intention to use it?
- EXR project doesn’t intend to use it
- OCIO didn’t know it existed (Carol)
- But we are using Confluence… John: yes, that’s used a fair amount.
- OK, if no objections, Andy can go ahead. John to provide paper trail
- Scott (chat): GitHub Issues is good enough for me.
No updated on OpenQMC
No update on Open Source Track at FMX
- David: we will reach out to some of you, one spot left for a presentation, has to be someone who is already in Europe, if you know someone who is part of our ecosystem who could present on an open source topic, please send their name to David and Emily
Security Threat model analysis for ASWF projects #615
- Some comments added to the ticket
- John: Don’t know if some projects have discussed it internally?
  - No updates
  - Please discuss at project level
  - Nick: for the 90% coverage, does that apply to OTIO the library, or OTIO the library + utilities + …? John: it’s a great question that leads into next topic…
  - John: the way the requirement is written, wording calls for “90% statement coverage”. So a FLOSS tool has to exist. Also does the project have the required hardware to do the testing. For demo code, that may be outside the goal, the focus is the core code. Nick: could we annotate this? Would like to forestall arguments in TSCs and avoid hair splitting. John: yes we can work to upstream with OpenSFF badge definition and for now annotate our own. Larry: for OIIO we do include the utilities, anything the user considers a deliverable, but exclude the viewer since there’s no practical way to do it for now. Nick: that seems like the model to follow. Eric: if we can come up with some sort of language, what Larry said is reasonable, but want project guidance. Don’t want to incentivize projects to not offer useful tools to avoid bringing down coverage number. Kimball: in OpenEXR, we make sure example code compiles, but don’t necessarily have deep tests, which seems reasonable. John: most projects may be able to get to 80% coverage, 90% seems more difficult. Larry: passing is 70, silver is 80, gold is 90%. Projects are struggling to hit 80%, and 90% is unrealistic without sucking up too many development resources. Cary: OpenEXR is at 82%, seems pushing it further would be diminishing return.
- John: We would omit some requirements until we have better language on how to achieve them.
- Reproducible build: a lot of projects don’t distribute binaries
- GitHub Pages and ReadTheDocs don’t put out headers to satisfy this requirement, but this is really meant for non-static sites.
- This is where we’ve landed, are there concerns to “box these out”? Larry: I’m still skeptical about “higher than passing” requirements as part of the adoption process at all. Cary: the ones listed here are the ones OpenEXR hasn’t achieved. I’m on board with security threat model audit, concern will be a fair bit of effort to be told what we likely already know, but would be good to be told we haven’t missed something obvious, so I’m up for that. I don’t see any of these requirements that OpenEXR is going to find valuable / worth our time. So I would vote in favor of deprecating these requirements. Alex: is this above OpenSFF? Isn’t OpenEXR already at 100%? John: this is for Gold level, OpenEXR is not at Gold yet. Carol: there are 2 important things here that we are toying with: security is important, in different ways for different projects in foundation. OpenEXR has gone furthest, but one reason is that this is a project where security really matters and can have big consequences. Would like to heard from projects where the time put into this may not be as necessary, do removing these requirements help getting projects to Adopted stage, since that’s the main goal. We’ve heard from projects that are close, we haven’t heard from projects that are not close. Eric: from OTIO perspective, one of the challenges is that our core team has declined a bit, where we have time to spend our attention, we are at critical inflection point of major vendors who want to adopt us but are asking for some critical features. So “which checkboxes” are more important to hit? I’m probably going to be more focussed on features requested by vendors. We would love to graduate to Adopted phase, but will be hard to find the time to do this. Also Jonathan brought up MaterialX statement coverage, since can’t run GPU code in CI. Creating a minimum bar for coverage may create an incentive not to turn on certain CI tests that would lower your coverage. Jonathan: these are all good goals, but reaching Silver/Gold should be separate from reaching Accepted status.
- John: thought were were closer to consensus, so we’ll need to circle back on this. Carol: don’t think we’re super far to updating the badge requirements, we should still do this. There are two separate things: adjusting the requirements, and tying Silver/Gold status to project Accepted status. David: we’ve talked about this a lot, can you explain if it is possible to separate the Silver / Gold from the Graduation of the project. John: the TAC can do what it wants, it aligns with what other communities have done. If the idea is that the TAC views these requirements as not necessary to move through the lifecycle. But seeing other industries that were in similar positions, they are more and more looking at these kinds of “gauges” to review the software they are using. Everyone is starting to require ways to gauge the quality of the software we use and produce. But if the TAC decides it’s not a tool it wants to use… Larry: no one is saying that this isn’t a tool we want to use, but advancing from from Incubating to Graduated (Adopted) shouldn’t be tied on Silver / Gold. The list of exclusions is likely good, but it should be an “extra mark of quality”. If foundational packages in our industry are listed as “Incubating”, that’s a problem. John: the TAC is welcome to do what it feels is appropriate for its lifecycle requirements. David: what needs to happen for the TAC to make this decision, is it a vote? John: yes, that would be a vote to change lifecycle requirements. David: can the TAC work on the wording of this proposal to separate the Silver / Gold requirements from the Graduating process and vote on that at the next TAC meeting? Larry: we’ve already graduated projects that didn’t meet those projects / made exceptions. Carol: yes, we can draft language and put it in a PR. John: please put a PR together. David: let’s do it
- From Chat:
  - Eric: OTIO is at 80%
  - Larry: I think OIIO is in the upper 7x% and every 0.1% extra is a lot of additional work. I am still working to get to 80% but I would have a hard time justifying going higher given the amount of work it took to get from 75 to 80.
  - Jonathan: MaterialX currently has 88% statement coverage in unit tests, but we’re intentionally omitting all of our GPU-based rendering libraries, as we don’t yet have a way of running their unit tests on GitHub Actions. Our progress towards a Silver Badge is stuck at 96%, with the last two requirements both being related to security.
  - John: I think the gaps from MaterialX are about the same as OpenEXR from my review
  - Nick: A concern I have is that if acceptance is gated on achieving these goals, it is a disencentive to overly invest in a project. Hey finance! We’d like to invest more in this project we want to donate to ASWF! Great, have they accepted the project? No, it’s gated on us spending hundreds more hours of work Umm, can you check with them, that can’t be right?
  - Larry: I think these are all good goals but reaching silver and gold should be entirely orthogonal to the transition from “incubating” to “acceptance”. It should be an additional merit badge or whatever.
  - Carol: Yeah. I mean I guess we really need to hear from LF why it’s not an option? Because it sounds like maybe its a problem?
  - Nick: The projects all feel like they are in a kind of limbo ~~ aswf logo-clouds all our projects, yet so many are not “accepted”. Very awkward ~ much prefer the “achievement” aspect, rather than “limbo” aspect.
  - Eric: I also want to reiterate - security is very important to me, especially in interchange formats where the files me make and read might be flowing across airgaps and aren’t likely to be able to be scanned for being maliciously malformed.
  - JT Nelson: As a contractor for the industry in the IT, security and dataservices channels, my focus and people like me are on MPAA security best practices compliance by content creator 3rd party studios. Just FYI https://www.motionpictures.org/wp-content/uploads/2015/11/sup_english.pdf
  - Larry: To close out the last topic, I want to reiterate that none of John’s work shepherding the OpenSSF requirements is wasted. We absolutely should keep going on this and try over time to have project meet as many of the requirements as possible AND have some kind of designation for projects that meet this high standard. My only grumpiness is that it shouldn’t be a requirement for incubation -> adoption.
Working Group for Rust Bindings #489
- Scott Wilson
- Presentation Slides
- Where We Were by Last Presentation
  - Progress Ground to a halt
  - Group focus at the time was misaligned
    - We tried to build C and Rust bindings to help see the Rust bindings
    - Focus on getting babble (formally cppmm) developed instead of using what was already available
- What’s Changed?
  - Changed priority to use binding generators that already exist (cpp, cxx, etc)
  - Changed meeting time from every second week to once a month
- OpenIMageIO Bindings
  - Reasons to build bindings
    - Relatively easy API to build bindings for
    - A useful library to have in the Rust ecosystem
    - I personally really like the library
  - Development in 3 stages
    - Unsafe “sys” bindings (slightly over half way complete) [https://github.com/vfx-rs/oiio-bind/issues/29]
    - Safe “API” bindings
    - Migration over to the openIMageIO project and crates.io release
  - Goal is to have the bindings ready for testing by end of summer
- PTex Bindings
  - Added wrapper for the PTex writer APIs
    - Supports writing halfs, floats and ints
  - Switched over to the cxx binding generator
  - Added wrapper for the reader APIs
    - Supports reading floats and face info adjacency data
  - Build system updated to better support pkg-config variables
  - Future plans are to continue on with the reader APIs and plan for a version 1.0 release
- USD Bindings
  - Progress has slowed down due to developer time and size of project
- Babble
  - Went through another rewrite to get a pybind style binding generator
  - Refocus on generating a C API then later Rust bindings from the C API
- Questions?
  - Larry: how do you decide to use cxx vs Babble? Pros and cons? Is it a way to get both C and Rust bindings? Scott: with cxx there’s still a lot of hand writing to do, you have to implement each function by hand, tell the binding generator how everything works. With Babble a lot of this can be automatically generated, with some caveats requiring human intervention. There’s also something called autocxx which I haven’t tried and can do something similar. cxx at a 1.0 release, already exists, being used, other packages depend on it. Babble can do some really cool things, but not ready for use yet. Will we want to replace everything we’ve done with Babble, or stick with cxx remains TBD.
- John: we will vote on renewal offline due to lack of quorum.
New Project Proposal - Pillow #631
- Jeffrey Clark “Alex”, forked from PIL
- Will explain how Pillow is aligned with ASWF
- In 2019 TideLift Lifter paid for work
- Lifter Advocate in 2023/2024
- TideLift is like a ‘RedHat for everything but the kernel”
- Working to learn on VFX + open source
- Lifter Advocacy
- Get a job in Industry
- Pillow + ASWF
  - Benefits to working together
  - We could use some help, for instance the CLA (Pillow currently has none)
  - Infrastructure, community: transitioning from Travis to GHA
  - Ran into Dev Days from October 2023, which got me interested, contributed to OpenImageIO wheels packaging. Got a lot of help from JC and Larry, not finished yet, but hoping to finish it.
  - Seems at ASWF still has a lot of “stuff” to be done.
- Specific Alignments
  - 1.5M repositories / 15k packages on GitHub depend on Pillow
- Infrastructure
  - JC helped to clarify what ASWF does for its projects, CLA seems most meaningful to Pillow. Larry clarified that dev resources are not provided.
  - Give and take?
  - Keep up with Python releases
  - Publish wheels for all ASWF projects
  - We have a security contributor who deals with CVEs
- Make Pillow and VFX better together
  - #1888 in Pillow issue tracker: support for higher bitdepth
- Thank you for the time to present!
- John: questions?
  - Michael: I’ve used Pillow before, can you give a brief overview of what Pillow covers? Alex: a low level image processing library for Python. Michael: are there operators like a “histogram”? Alex: all matters from basic operators, resizing, blurring, changing image type, the proposal has the right description. We carried over the PIL documentation, lots of great tutorials and examples of how to use. Also quite common in data science, some overlap there.
  - Carol: thanks for the presentation! Everybody appreciates the importance and prevalence of Pillow, I’m not sure that “alignment” works here. We may alignment philosophically, but it can also meant the project ecosystem and applications. Would be interested if there are examples of using it in VFX, and if not, that’s not necessarily a bad thing. We could be collaborators, but moving a project into ASWF may not be the best fit? There’s a lot of things that Pillow does that OIIO already does and has Python bindings for. There may be other places which are a best fit? We have a focus / scope… Alex: yes, I agree with that. Carol: that’s just my opinion of course, and would love to see more. Also if you have directions you are planning to take the project that would relate to VFX? Alex: since I don’t work in VFX, that could be difficult. The opportunity to jump into a working group like this is rare, for instance I don’t have a way to reach out to data science industry. Scott (chat): I agree with Carol. The VFX use case is probably a subset of what Pillow is/can be used for. I wouldn’t be surprised if there’s another group within the Linux Foundation that would be an excellent home, but we’re happy to have you hear no matter what!
- John: thank you, we will further discuss the proposal at next TAC meeting