ASWF TAC Meeting - March 27, 2019

Voting member attendance

Apologies

Jim Jeffers, Intel Corporation
Cory Omand, The Walt Disney Studios
Ken Museth, OpenVDB Representative
Henry Vera, Double Negative

Other Attendees

John Mertic, Linux Foundation
David Morin, ASWF
Mark Elendt, SideFX
Thanh Ha, Linux Foundation
Andrew Pearce, DreamWorks

Agenda

Goals for TAC: Year 1
Governing Board meeting update
- Update from David Morin
  - Open Source Summit at Half Moon Bay
  - RedHat is now a General Member
  - FTrack joining as a General Member
  - Planning for SIGGRAPH “conference within a conference”
  - Board meeting was very positive about the TAC
- Update from Daniel
  - Present option to move to CircleCI vs goal of a reproducible CI infrastructure
  - Board feels that if on balance it is a benefit, projects can take advantage of CI technology, and if costs are OK, then the board is happy to support based on TAC guidance
  - Short discussion about mission of ASWF and what types of projects are candidates, projects such as OpenCue that haven’t gained wide acceptance yet. Consensus seems there is no problem taking on projects in order to drive adoption rather than needing that as a prerequisite.
  - Question of how to corral resources (commitments from members), especially in context of OpenColorIO. For now FTE commitment was left very general (“any open source activity”), but soon should think about specifically assigning those resources to ASWF projects. Larry: maybe too early to put on pressure to force commitment to ASWF projects only, but more direct members who currently have unallocated resources.
Thanh announcement
- Leaving Linux Foundation for a startup
- Andrew Grimberg taking over his role for now, is caught up on all issues
Technical Project updates
- OpenVDB
  - Work focussed on CMake updates, testing with CircleCI
- OpenColorIO
CI updates
- Working group discussions
- Some entrants for challenge that was set, no fully complete solutions, but Aloys got close with OpenEXR builds including Conan, CI system itself is a thin layer on top of recipes for package management, sourcing dependencies, and build (CMake) recipes.
- Enthusiastic takeup on CircleCI, that style of CI system seems quite appealing.
- We discussed other approaches, including Azure Pipelines, currently supports all 3 platforms. How does pricing compare to CircleCI? No understanding of GPU support on Azure. Looking to follow up for next week’s meeting.
OpenCue proposal
- Vote on adoption to incubation stage
- We have quorum (exactly 50%)
- DreamWorks and WETA were going to take a closer look at project. Dreamworks: scheduling is done on a per core basis, much more rigid than the way they currently schedule. They use percentages across shows rather than allocating cores to projects, which gives them high farm utilization, possibly higher than OpenCue approach. OpenCue takes a “every core is created equally”, they look at other aspects of the system. OpenCue couples the database to the scheduler, so if the DB goes down, scheduling would stop. Their approach relies less critically on the database. The OpenCue scheduler doesn’t expose a REST API, uses the Google Remote protocol instead, Dreamworks would prefer a REST API. In current state Dreamworks would probably not adopt OpenCue. Daniel: does Dreamworks see advantage to a common open source platform, could some of these features / approaches be put into a project like this? Bill: they probably wouldn’t contribute to this project as highest priority.
- Brian: a lot of these feedback points are on the roadmap for future development, and they want to see more of this feedback from the community.
- Kimball: some commonality in design with their in house system. Whether they would adopt it in the short term is orthogonal to the worth of the project being adopted in the ASWF. Good thing to have a project under active development, and they think it would be valuable to have it.
- Eric: are there people / companies currently not contributing to this project who would contribute if it became an official project? What’s the practical difference being adopted vs not adopted? Kimbal: definitely some marketing exposure. Larry: reception on the long run would be better than a single studio / vendor project. Kimball: opportunity to see a new and vibrant project to grow within the community, model for new projects with larger / deeper scope. Brian: even if some of the TAC members aren’t contributing directly to code, having guidance from large studios would help to drive development. Todd: there’s an incubation period, so if we don’t see adoption, there’s a “way out” / other projects could take its place. Daniel: will add link to project lifecycle document.
- Larry: if the model is that an incubating project may not graduate out of incubation, what happens to all of the material that got signed over to the foundation going into incubation (mailing lists on ASWF, project home on GitHub, signing over trademarks…). Is there a process for “spinning out” a project from incubation?
- John: if a project is deemed that it should live elsewhere, ASWF can spin out assets to another entity, but not spelled out directly in lifecycle template, could use some clarification. If no one wants to pick up the project it could go into archive stage. Intent is that if a project enters incubation phase, it is expected that it will become a full fledged project.
- David: first “new” project under consideration, we can rely on the templates provided by the Linux Foundation, but we can define our own process to address these questions, and the TAC is the correct body to make these decisions. It is important to add these questions at this point. The LF provided great templates based on previous work / experience, but we are free to adapt and change.
- Daniel was given voting positions by some of the people who could not attend, but can’t present those if we are taking an in-person vote. So we should take this to an email vote. Daniel and John will set up a vote to take place ASAP after the meeting.
Vector / Matrix library
- Intense discussion for a while, but has tapered off.
- Larry: summary is that we are trying to grope our way towards a minimal implementation that all projects could use for their public API, and perhaps for internal implementation, while leaving room for bit-accurate internal implementations. Luka was looking at whether they could share their internal designs (now that OpenEXR has applied). With EXR we have two separate projects with their separate implementations. But not much movement apart from mailing list discussion. Kimball: should it be part of IlmBase or a separate project. Larry: topic of split between IlmBase and OpenEXR proper has come up, application to ASWF gives forum to discuss this. No rush on this, and ASWF is good organization to tackle this.
- Eric: has someone looked at GLM vector library? Larry: bigger than what he was thinking about. Larry: Eigen sometimes cited as something that projects explicitly don’t like to swallow as a dependency? We want to take advantage of new fp16 instructions on recent CPUs.
Update on candidate projects
- OpenEXR
  - Proposal received 25-Mar-2019
  - Can concentrate on voting next meeting once OpenCue is done
  - Should discuss on TAC mailing list
  - This will bring the 3 headline projects discussed during ASWF formation
  - We should start looking wider for other projects
- Others?
  - Kimball: CMake tools should probably not be a full project, still part of foundation. But raw2aces and photo developing project could still be a good candidate.
Next meeting

Action Items (AIs)

Notes

Chat