ASWF TAC Meeting - June 02, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, Linux Foundation Release Engineering
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Matthieu Mazerolle, Foundry
Ashley Whetter, Python 3 WG
Carol Payne, Netflix / D&I WG
Sergio Rojas
Scott Wilson, Rust WG
Deke Kincaid, Digital Domain

Apologies

Bill Ballew, Dreamworks
Joshua Minor, OpenTimelineIO Representative

Agenda

Project lifecycle updates (revamp / breakdown of John’s original pull request)
- PR 267: codifies what we’ve done previously, adds a bit more structure, matches our practices up to date. Slight wrinkle to have projects submit their proposal and give the TAC a bit of time to review (2 weeks?). TAC members to have time to review and speak at next meeting. In the past annual review has been focussed on projects in Incubation Stage. This codifies that all projects should get annual review, adds some structure. Other communities have adopted that. Not so much you are “going in front of the court”, more an opportunity to have a touchpoint with the TAC. Kimball: don’t have a concern with that wording. Should structure these throughout the year so we don’t have all the reviews at the same time. Kimball: wanted to do a deep dive on WGs and projects on a regular basis (OpenVDB hasn’t attended in a while). John: we can keep track of that, have something on the TAC site to track the dates. Cary: this is somewhat similar to the Silver/Gold badge requirement. It is valuable as a whole to hear what is the state of each project. John: this can also be used as an exercise to create “project health reports” that can also be external facing. Project health is important, also want to make sure that projects don’t feel like they aren’t getting proper attention.
- PR 270: archive stage Some concern from Larry: don’t want to force a project into archive stage by the TAC, should be a decision of the project. Commit activity may not be a correct sign of project activity. Criteria ought to be “is this a project the industry doesn’t need anymore”. Can imagine a project that doesn’t need activity (feature complete / no bugs are found), just because commits aren’t happening is not a sufficient indicator. Also showing “churn” just to demonstrate activity should be a non-goal. Larry: archiving should mean “this is a project that isn’t important / relevant to the community anymore”. For instance a replacement technology may come out that makes a project no longer important. Also if a project isn’t getting the developer attention it needs, that’s where the TAC needs to marshall resources. John: once something goes into Archive mode, it’s not necessarily dead, it could always be brought back.
- PR 268: Sandbox Stage Projects forming within the foundation instead of outside. Requirements are fairly low, basically just the proposal and how it can add value. Benefits is mostly infrastructure, but TAC wouldn’t be spending a ton of time. Also a place to put a lot of the processes in place that would normally be part of the onboarding process. Could projects just want to stay in Sandbox project? John: probably an “anti pattern”, typically a project would want to stay in Sandbox for a limited amount of time. Is there a place in our foundation for a “one person project”. Some communities find that this isn’t quite as valuable, want wider “buy-in”, other communities take the “if not here, where else?” approach. JT: Pasadena group is using Sandbox model, seems to be working well, especially for tech startups. Demonstration of how it works might be useful. Could have someone come and present on this sandbox topic. Larry: hard to judge without some concrete examples, would be a bit worried if projects not up to our quality standards could join to just get the “halo effect” without going through all the steps to make it through incubating / graduation project. JT: want these groups to join. John: CNCF gets 18 incubator projects in a TAC meeting, so have a lot of similar concerns. Projects want to ride the brand affinity. They want the sandbox stage to timeout after a while, if it isn’t moving after a while, encourage moving somewhere else. Kimball: could take longer than a year for incubation. Eric: sounds very “case by case”, maybe put it in the rules and see how it goes for a couple of years?
- PR 269: Adopted Stage Main stage is change to Gold level badge, and clarifying benefits.
- PR 242: Working Groups Kimball: for instance has Python 3 WG has achieved its goals, should we extend it, change its charter?
Report on the CII badge lift (gold stars for everyone!)
- Cary: looked at badge requirements for silver level. Marked a number of them. They fall into 4 categories:
  - Easy ones, filled them out
  - Issues that need some discussion, either don’t apply, or need clarification as to what they mean
  - A few issues seem worth doing: a published roadmap, quickstart guide (OpenEXR kind of already has that), making sure the documentation is as accessible to newcomers as it should be, requires cleanups
  - Some issues that are workflow issues that we wouldn’t do otherwise, but we could probably accommodate them if we decided to go for the badging
- Overall, Silver and Gold levels are not out fo reach
- For example, project has a requirement of an “uninstall”, which is not provided by CMake, not clear what to do about that.
- Cryptographically signing releases: previous maintainers signed the tarballs, but let that drop by the wayside, wasn’t clear it added value. But we could bring that back. Have figured out how to generate the signatures based on the GPG keys, other half of the equation is how do people who want to verify the signatures get their key? Unclear on that process.
- Kimball: usually you publish your public key to a public repo. Andrew: distributions all have an automation key they use, so artifact producing CI systems have a key they use. For more Linux distributions, they have a specific key for every major release (for instance Fedora 34, Fedora 34…). LF is running internally on Jenkins a system called Sygill which was developed for Fedora, can maintain signing keys in a way that is safe for CI systems, the key is never on the actual CI build agent. The build agent uses a different key to request signing from a signing server. Looking at how this could be provided for platform CI systems (GitHub Actions for instance). Already doing this for OpenDaylight, which have specific signed release artifacts. There is also the concept of “attestation” for developers that generates keys on the fly stored in a public ledger, but doesn’t work as well for release artifacts. Cary: looks like something LF RelEng is something it could help use with.
- Eric: what’s the cost/benefit of going to a higher badge level? There’s already a load for onboarding new projects. Andrew: don’t need to meet all those levels to join at incubation level. Eric: but if a project joins ASWF, it is typically to become a “full” project. Cary: our existing projects follow best practices, and can serve as examples. Larry: depends on what’s on the list that our projects follow, versus “jumping through hoops”. Cary: as far as OpenEXR is concerned, not very far away from meeting requirements. Daniel: CI WG / LF RelEng can work on release signing, and could get “for free” by adopting ASWF CI pipeline. Kimball: this was one of the items that was on the proposed list of changes to the project lifecycle. Andrew: after Solarwinds incident, as well as other pushes from federal govt around security of software supply chain, LF will push more on projects to meet these requirements. Kimball: simple things like the roadmap is a no brainer that doesn’t have implications on security. Roadmaps would help communication with VFX Reference Platform for instance.
Reviews for summer learning program?
- Carol: had a few more folks sign up, please recommend anyone else who might be available, need reviewers more urgently than mentors. The more reviewers, the less work each person has to do!
Project / WG updates
- Assets WG / Wave
  - needs TSC & community members to add to this wish list: https://wiki.aswf.io/display/ARW/Wish+List
  - What assets would projects like to see / need for their uses
- OSL / Chris
  - Nothing major to report, getting a bit closer to approving the logo, selected the shape, tweaking the colors.
  - Kimball: are you doing a release for SIGGRAPH? Larry: just sent an email about doing a major release, even though OSL is not part of VFX Platform, use and are a dependency of VFX Platform components, so aiming to be in beta by SIGGRAPH.
- OpenEXR / Cary
  - In the midst of a minor release that comes out tomorrow, fixes a small glitch in the last release. Moving towards a 3.1 release before Open Source Days, includes work from Kimball on acceleration, half type, C API, threading improvements in OpenEXR core.
- OpenCue / Brian
  - Working on Python packaging process. Working on the GUI component of the system.
- OCIO / Michael
  - Preparing on SIGGRAPH long course, recording is due end of next week.
  - Nice technical improvements in progress, hopefully part of OCIO 2.1 in time for SIGGRAPH
    - New OFX nodes so you can use OCIO in Resolve and other OFX aps
    - ACES 1.3 gamut compressed PR
    - iMath 3 support for half type dependency
- OpenVDB
- OpenTimelineIO
- Diversity & Inclusion
  - Carol: haven’t heard back from SIGGRAPH D&I summit
  - Monthly meeting next Wednesday, open invitation to TAC members
  - Summer program
  - Want to discuss the Adobe Open Framework proposal with Bill Roberts
- Python 3 / Ashley
  - No new updates. Kimball: WETA finally have a Python 3 working environment, should have live productions running by end of year
- USD
- CI / Daniel
  - Main topic has been VFX Platform and set of associated issues, sunsetting older versions
  - Related to supply chain issues: LF has been working with JFrog to get an open source account to give us access to Artifactory Pro and XRay, a product analysis tool, analyses dependencies.
  - Larry: if the projects are trying to sync releases with SIGGRAPH, they are all grappling with how far back they need to support the VFX Platform. We need more guidance.
  - Daniel: this is an abstract issue we can fix in practice. We can enact a specific duration, and see if that’s accepted.
  - Larry: a lot of projects have dropped anything earlier than C++ 14, which de factor drops support for VFX Platform before 2018. Daniel: will bring that back for next TAC meeting.
  - Kimball: will arrange to have Nick/Francois from VFX Platform to show up for an upcoming meeting. Daniel: also took an action item for discussion on Wayland.