Academy Software Foundation - Technical Advisory Council (TAC) Meeting - November 29, 2023

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

Voting member attendance

Premier member Representatives

Project Representatives

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

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non Voting Projects, Working Groups, Linux Foundation

Other Attendees

Joseph Goldstone, ARRI
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Robin Rowe, CinePaint
Lee Kerley, Sony Imageworks
Deke Kincaid, Digital Domain
Doug Walker, OCIO / Autodesk
Olga Avramenko, MPC

Apologies

Scott Wilson - Working Group for Rust Bindings Representative

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

Annual Review - OpenColorIO - Followup Vote #474
TAC Meeting Schedule - December 2023 and January 2024 #546
Project Proposal - OpenQMC #434
Transition to LFX Meeting Management #460
Call for Proposal and Program Committee for Open Source Day
Discuss use of OpenSSF Best Practices badge in lifecycle stage requirements. #502
Annual Review - rawtoaces #475
TAC Chairperson and Industry Representative re-election #537

Notes

John: Kimball unable to make this meeting
OpenQMC: we are getting closer, trying to get wording in place with folks from Framestore. If anyone from TAC interested in reviewing the wording, please reach out to Eric E.
John: two projects left to join LFX, just OpenEXR and OpenCue. Some issues with Outlook, meetings off by 30 minutes, please file a support ticket, there may be a “legitimate” issue. Outlook seems a bit quirky, would be good if we can get those issues debugged with LF support. If you login to the web site, you will see the canonical version of your calendar.
Schedule for TAC for next two months affected by Holidays and LF offsite
- Meeting on December 13th as is
- Cancel 27th December
- Meeting January 10th as is
- January 22nd overlaps with LF offsite, any objection to cancelling it?
- Resume normal schedule on 2024-02-07 (or 08?)
Will be sending out a joint maintainer / contributor survey, renamed as “stakeholder survey”, opened for all of December. Will do some analysis and publish results. Hoping to have better data, get feedback on programs, want to run it every 6 months and try to track trends around satisfaction. Look for announcement, wide scope of respondents
Renewal of Industry Representative status (JF / VES Technology)
- We do not have quorum
- Yarille will run vote over email
- No concern over renewing
TAC chair renewal, usually after the beginning of the year. Kimball has been doing it for a couple of years, he’s open to someone else doing it. Please reach out to John if you are interested, what it means / what it’s about. If we have multiple interested people, we will have an election.
Waiting for OpenColorIO deck for the vote on a couple of things:
- Annual renewal vote? John: it’s more a formality than anything else. Yarille: we didn’t have quorum at the time. Carol: sent you the slides, should be enough for that vote.
- OCIO asking for a separate vote about a new concept, a WG under OCIO which has cross project interop involved, wanted to get TAC approval for this effort, or a statement of support of how OCIO is thinking of approaching. Carol: thought I needed a written proposal for that.
- But the slides are enough for the OCIO renewal vote. John: don’t really need to vote on something OCIO wants to do within its mandate. Carol: no problem with that.
rawtoaces pushed to future
OpenSFF Best Practices
- John: GH Issue with more content
- Jonathan: we’ve allowed a bit of a split to develop between what we perceive as an adopted at ASWF vs the technical goals we have stated are requirements. OpenEXR and OSL should obviously be adopted projects, their relevance to the industry justifies their adoption, but they don’t meet the technical requirements we have set, and that’s something we should fix. Makes it hard to judge new projects against these criteria. The example brought up was the Gold OpenSFF badge, we want all adopted projects to be making project towards, but since no project has achieved it, it seems not a good approach to hold projects to that requirement.
- MaterialX is working towards Silver badge, which would be followed by a Gold badge, but requiring a Gold badge before a project can be adopted seems a problem. Only 10 open source projects have achieved a Gold badge. We should make the requirement progress towards Gold.
- John: historical projects that were adopted before we changed the requirements were grandfathered in, but there should be a level of consistency.
- Anyone else interested in chiming in?
- Carol: is Gold currently a requirement to become an adopted project? John: yes, it was changed when we added the Sandbox stage. Carol: didn’t realize this, we should drop it down to Silver. Jonathan: it is a hard requirement, but seems many didn’t realize this, especially the projects that were initially adopted before the requirement was added.
- Jonathan: link to requirements. We voted in OSL to Adopted status without having met either Silver or Gold badge requirements.
- John: Gold Level requirements
- JC: don’t we have a loosened version of badges from ci-wg discussions? We tried to help with those requirements, and perhaps lower the bar on some requirements like code coverage percentage, 90% being very hard to reach, and other problematic issues such as reproducible builds. We had talked about having our “own” version of badges.
- John: we tried to add more context around some of the requirements, code coverage was a specific one. One of the questions was around conditional builds / hardware / platform dependencies. The compromise would be that if you don’t have access to the hardware for testing, you can back off automated testing for platforms you don’t have access to.
- John: also some exceptions around reproducible builds. JC: yes, that’s my recollection as well.
- John: are there other problematic requirements? JC: code signing, Rez and MaterialX is looking into it.
- Jonathan: these are all worthwhile goals, but not all goals are worth holding projects up to. Carol: not fair to hold projects from being adopted just for not meeting a Gold standard when none of the existing adopted projects have achieved that.
- John: is there a desire to get some of the historical projects to that level, or does the group think the Gold requirements are not relevant?
- Nick: different people may have different interpretations of the requirements, we should have a survey at the TAC level, make a spreadsheet across all projects, without a dashboard it will be difficult to make progress. John: a central effort coordinated by the TAC? Nick: yes, if done at the TSC level, it will fight for other priorities. Carol: a lot of the TSC members know that this is important, but are not SMEs in security for instance, so hard to evaluate the time commitment, what needs to happen to meet the requirements. Most of the projects don’t have this kind of talent (especially for security issues). Makes it hard to prioritize it. OpenEXR is different since it is exposed in other contexts (part of OS). OCIO should work towards this, but how do we prioritize it against all the other requirements. We don’t have extra dev cycles, so is the ASWF TAC asking projects to remove resources from features to meeting these requirements. Until the TAC gives a mandate and a deadline, it won’t happen. Nick: every time a security requirement is brought up, it is suggested that a TSC member should take training to get certified in security, but we don’t have this time to dedicated.
- John: would specific steps to be accomplished something that would help give clarity to the TSCs? We would make this explicit to avoid ambiguity / interpretation.
- Erik N: it always helps to know the scope of the problem. Would it be a good exercise for the TAC to figure out which projects have the highest security exposure and understand the scope of that exposure. Build a plan to focus on highest priority.
- Eric E: could change acceptance requirement from overall badge to specific requirements? John: the badges are a framework around project operation, if you have these infrastructure pieces in place, it doesn’t mean you’ve solved all your security problems, it means you’ve put the processes in place. But it’s not just security, it’s also project sustainability in general. One big challenge is that we’re splitting hairs instead of having specific requirements / steps to take to make progress. For instance requirement for uninstalling. Some of that may be a next level thing to look at, pick out the stuff that doesn’t matter.
- Nick (Chat): Silver is incompatible with reasonable usage of cmake. “The project MUST provide a way to easily install and uninstall the software produced by the project using a commonly-used convention. {N/A justification} {Met “
- Erik N: do projects use security scanning tools? John: not sure we have done that formally. Jonathan: most of our projects use static and dynamic analysis, some of the issues get flagged by those scans. Most of our projects already run those scans, and there are aspects of the badges that cover those requirements. I do think that many of the recommendations in the OpenSFF badges are good, and our project has benefited from the testing requirements. It’s more using the Gold badge as a gate we should step away from, and none of our projects have passed that.
- Erik N: sounds like the badge needs to be underpinned by clearly measurable metrics, and projects should have to undergo a periodic review to maintain the badge. Jonathan: but none of our projects have achieved a Gold badge, so maintenance is in the future!
- John: this could be covered in the annual review process, could be plugged into there.
- Jonathan: Passing badge in OpenSFF has strong ASWF goals, and it’s a good requirement for Incubation stage. Achieving that badge was revelatory for MaterialX, and was very useful.
- Erik R: OTIO has adopted a “federation of repos” approach, we have a core repo, then separate repos for GUI apps, adapters… Those other repos aren’t the primary project, separate. Do we have to hold all those things to the same standard, or does it only apply to OTIO core?
- John: although wg-ci has done some work, sounds like there’s “next level” analysis of the requirements needed. Seems like a missing piece that’s complicating things.
- Carol: I think this would be helpful to have projects continue to work towards those requirements, these are “good things to do”, no one is really arguing against that, except for requirements that aren’t achievable. Signed releases may not make sense for some projects for instance. How do we help existing accepted projects to make projects towards Gold badge, and how to we come up with clear steps to get there. But the other discussion should be to remove the Gold badge requirement to become an adopted project. We’re likely to adopt project in the future no matter what.
- John: seems to make sense, what is the requirement for adopting a project? There seems to be different directions for this evaluation. We could go one for a long time, but we don’t have quorum. Where I have seen a challenge is that when you are in a subjective area, there’s not a clear outline of how to get there. How could we measure characteristics so a project and see if it’s ready. Jonathan: could the tweak to the language to be to “have made notable project towards a Gold badge”. We would be stating that the Gold badge is aspirational, have made progress about Passing badge (JF: what about Silver?). The other requirements we have placed around project relevance and acceptance are already capture well.
- JF: does the TAC still have a role to influence adopted level projects?
- John: there can be “progress” after Adopted level. Could the TAC set an expectation that a certain amount of time after adoption a project reaches a specific requirement. There are still strides and improvements a project can make after adoption?
- Carol: passing should be the guideline for adoption, and we need something clear and measurable requirements from projects, especially around reviews
- John: this has been a good discussion, will start a PR to capture where I think everyone is at, will share with the group, we can continue the discussion and if we get some alignment, we can review at the next meeting. We can go back to ci-wg to come up with a practical guide on how to achieve there requirements for project, take the work we did and get it into more concrete steps.
- Jonathan: this sounds great, the concrete change that would make the most sense would be to make sure that all adopted projects meet the requirements we set.
- John: will take a stab at putting something together in time for next meeting.
Agenda of upcoming reviews may be reshuffled to get OTIO come before OpenEXR and give a full meeting per project review