ASWF TAC Meeting - September 23, 2020

Video Conference Link

Voting member attendance

  • Daniel Heckenberg - Chairperson, Animal Logic Pty Ltd
  • Gordon Bradley, Autodesk
  • Blue Sky Studios, Inc.
  • Michael O’Gorman, Cisco Systems Inc.
  • Henry Vera, DNEG
  • Bill Ballew, DreamWorks Animation
  • Matt Kuhlenschmidt, Epic Games, Inc.
  • Brian Cipriano, Google & OpenCue Representative
  • Sean C McDuffee, Intel Corporation
  • Larry Gritz, Sony Pictures Imageworks
  • Jean-Francois Panisset, VES Technology Committee
  • Cory Omand, The Walt Disney Studios
  • Kimball Thurston, Weta Digital Limited
  • Eric Enderton, NVIDIA
  • Sean Looper, Amazon Web Services
  • Michael Min, Netflix
  • Michael B. Johnson, Apple
  • Dave Fellows, Microsoft
  • Sean O’Connell, Advanced Micro Devices
  • Laurent Ruel, Unity Technologies
  • Ken Museth, OpenVDB Representative
  • Michael Dolan, OpenColorIO Representative
  • Cary Phillips, OpenEXR Representative
  • Joshua Minor, OpenTimelineIO Representative
  • Chris Kulla, Open Shading Language Representative

Other Attendees

  • John Mertic, Linux Foundation
  • Emily Olin, Linux Foundation
  • David Morin, Academy Software Foundation
  • JT Nelson, Pasadena Open Source consortium / SoCal Blender group
  • Ashley Whetter, Python 3 Working Group / DNeg
  • Carol Payne, Netflix, Diversity+Inclusion WG
  • Rachel Rose, ILM, Diversity+Inclusion WG
  • Nick Porcino, Pixar
  • Alex Meddick, Rising Sun Pictures
  • Stephan Steinbach, OTIO
  • Darby Johnston, RV
  • Patrick Hodoul / Autodesk / OCIO
  • Deke Kincaid / Digital Domain

Apologies

  • Bill Ballew, DreamWorks Animation

  • Kimball Thurston, Weta

Agenda

  • Goals for TAC: Year 2

    • Extending CI to GPU: done, further generalization desired

    • Extending CI to macOS and Windows, Apple Silicon

    • Diversity & Inclusion goals, good progress from D&I WG

    • TAC leadership

      • Daniel: chair tenure is now 2 years, there is no formal “maximum term”, but should be discussed

      • Should we institute a regular process of reaffirming / re-electing the chair, instead of the current informal process

  • Google Summer of Code Wrap Up

    • Summary from the 3 projects with GSoC interns

    • OpenCue (Brian): had grad student in US, worked on cloud plugin for OpenCue to manage cloud instances from OpenCue GUI. Supports GCP and Azure, AWS is in progress. Not merged yet, looking for some testers before merged into mainline. Overall went great, very beneficial to the project, establishing pipeline to bring new contributors into the project. Ended up with 20-25 applicants, about half turned into formal applications. That ended up being a big job to communicate with students and review applications, but once started it wasn’t such a big load. Wrap up took a few days, put together a blog post (see https://opencue.io blog), get code in shape. Biggest lesson was to have good material in place to bring new developers into the project: how to get started, set up dev environment, good first issues. Hopefully now that this is done, next time we need to onboard someone it will take less time. This is beneficial to the project no matter what. Could have perhaps handled 2-3 students, depending on how engaged the other TSC members are. Another lesson learned: identify potential mentors in the lead up to such a mentor, make sure they are engaged, same as identifying committers to the project. Keep in mind “who would make a good mentor”. Would like to see expanding this beyond GSoC, perhaps a summer and a winter session. Would doing it outside of GSoC might get a different kind of applicant? Some of the GSoC applicants may have been more interested in the GSoC credential rather than being actually interested in the specific project.

    • Eric: mentioned setting up dev environment and vetting the initial candidates. Brian: a lot of it was one time work due to newness of the project: add to add documentation for Windows setup for instance. Didn’t spend a lot of time walking potential applicants through submitting a first PR. Daniel: we required an “initial PR” as a proof of commitment, side effect may have been extra load on the TSC members. Brian: yes, but it was worth it, now have a lot of this infrastructure in place for next time. Should keep the requirement in place.

    • OpenEXR (Cary): imath and general usefulness to industry was raised early on by the community, languished on wishlist, but seemed like a good GSoC project. Had 3 competent applicants for the project, took on Owen Thomson from Rochester Institute of Technology, just finished program in Motion Picture Sciences, good fit. Didn’t involve writing a lot of actual code, but meant treating a lot of existing code very carefully to avoid breaking backwards compatibility. 1- creating new repo 2- moving code from existing to new repo, reorganizing, retrofitting OpenEXR cmake infrastructure, updating documentation, modernizing code (constexpr, CUDA decorators, making it compile with CUDA Half type). Exception handling, remove dependency on IEX library, clang-format, adding unit tests. Met with Owen 30 minute a week, Kimball as well, then attended TSC meetings. Set up test repo to experiment with moving code. Probably spent about 5hrs a week on this project over the course of the summer. Some of the technical skills required were C++, some of the issues are tricky, constexpr, peculiarities of CUDA. Owen was familiar with git, but needed to know more about administrator level knowledge, as well as GitHub repo management. He learned a lot about CMake and CUDA. Soft skills required: consensus building (how should the repo be structured, naming conventions, these hadn’t been fully worked out). Required flexibility, willingness to iterate, submit as a PR and deal with comments. Sometimes direct guidance would then be commented on by other OpenEXR contributors and required adjustment. What went well: the new repo is in good order, it works, no significant missteps along the way, nothing got messed up. It could have been a mess, there’s no guarantee that someone without substantial background in a long running project would be able to make this work. Showed up to all the TSC meetings, and he got a good education, engineering skills, was profitable for him. What could have gone better? Was hoping to be able to release by end of summer, but we’re not there yet. That’s more an issue with the project itself, lack of availability from core contributors, would have needed more time to reach that milestone. A suggestion to Owen in the spirit of a “performance review” at end of the summer: he wasn’t quite as communicative as could have been desired, his email communication could have been more proactive, was also hoping to use GitHub issues as a communication channel, but that didn’t end up happening as hoped for. Didn’t get as much community engagement as would have been desired. For next time: regular checkins on a weekly (or more frequent) basis are crucial, mentor must be willing to make that commitment. Should be more explicit about process to follow, set explicit milestones and deliverables, it would have been a more rewarding experience to have an actual release / milestone / deliverable at end of engagement. It is beneficial to the project, but also community engagement, we are offering an education to the student. Brian: found similar issues with communication from student.

    • OTIO (Joshua): very pleased with result of GSoC. Intern, Karthik, was very productive and proactive. We should emphasize the selection process at the beginning to avoid getting someone who won’t be successful. He learned a lot through the process, was able to complete main and stretch goals, as well as “surprise” PRs that he contributed. Nick spent a fair amount of time working with Karthik. Not many video calls, would have been better to have more. Nick: Karthik was amazing, on his own initiative he kept thinking of new initiatives, mocked up a proposed a PR with a compositor for the viewer. Many pleasing moments. One lesson: the project values correctness and functionality, builds that support PIP. If these had been laid out up front (for instance every new function must have a positive and negative unit test). For instance first contribution was interval algebra, requirement for test suite came as an “afterthought”, would have been better to anticipate that upfront. Another big project was wrapping OTIO APIs in C, took a fair amount of investigation since many possible approaches. The pattern he picked seemed to pass muster, he went through and wrapped hundreds of functions, but there wasn’t a design clause. Nick didn’t have a chance to inspect the design, it took a lot of time investment to check the work, validate that the tests worked, discover that some things are not obvious to a student. So “noun / verb / subject” pattern not consistent. Made a dozen a work items in response to C integration that need to be addressed outside the GSoC process due to time constraints. But still very successful, huge undertaking, he was very thorough and didn’t make mistakes. Other large project was Java bindings, lucky that contributors from Netflix provided help and guidance, they are likely to be primary consumers of the API. Karthik was able to take on all this feedback, integrate a memory management model that felt native to both C/C++ and Java. Managed to deliver this. Joshua: communication from GSoC teams: they were very strict about deadlines, regardless of current WfH situation, even for missing deadline by a few hours. Unclear what timezones times on the GSoC site are in.

    • OpenTimelineIO GSoC student final report

    • Larry: it sounds like all 3 candidates “knocked it out of the park”, the 3 projects would likely want to do this again. 2 projects didn’t get a “slot”, one project joined ASWF too late. Should we presume we want to do this again? Should we ask for more slots? What is the limit of how many students we could take on? We don’t have to decide this now. Joshua: would not want to have more than one at a time, time commitment would be too large. Wave: was there any communication between the students across channels? Brian: possibly not. Cary: Owen mentioned there was a forum (on the GSoC side) for students to communicate with each other. Some students on other projects mentioned that they didn’t get much mentorship. Wave: might be a good idea to provide some explicit way for ASWF interns to communicate with each other. Joshua: emphasis was to incorporate Kartic in OTIO communication channels, but would be helpful to connect the students together. Brian: would make sense to create a Slack channel for next year. Carol: from D&I perspective, improving this process and onboarding would help. Nick: Slack is a very useful channel for this.

    • Larry: great summaries from everyone, we can pick up further discussion on the TAC mailing list / Slack channel. Let’s do it again next year, expand it so that every project can get one student, unless a project decides it wants more than one student (seems a consensus that 1 is about right).

  • Follow ups

    • Recommendation for VFX Platform Long-Term Support

      • Larry: 8 years into VFX Reference Platform

      • Multiple “walls of compatibility”

      • How far back should we support? CI currently only supports a couple of years back

      • Cross project dependencies (OCIO / OIIO)

      • Daniel: OpenVDB has clear policy of 3 years back (2018-2020), only project with clear policy. CI supports 2018 and on via containers.

      • Availability of RedHat DTS for download

      • Larry: does OpenVDB not issue patches for older versions? Many studios use Maya versions that still rely on gcc 4.8. Daniel: will ask OpenVDB folks explicitly.

      • Daniel: Any statements from other projects?

      • Larry: don’t want to keep things running “forever”, can know what are the oldest versions used at his studio, but don’t know about other studios. Gordon: episodic TV clients may run very old versions. Official Autodesk position is “3 releases back”. Joshua: how do we know what’s in use out there? If we only base ourselves on big studios, does this leave smaller facilities behind? Would a survey of ASWF users would help? That would give a data point. Larry: there is “strength in numbers”, don’t want to be the only project to have a strict cutoff policy. Wave: the bigger the studio, the older the software they are locking on. A survey of ASWF organizations may give a conservative number.

      • Daniel: action item to look at a mechanism to gather usage / version information.

    • Vote: Policy to use non-paid Slack with guidance to move important discussions / decisions to other formats

    • Document security best-practices

  • Working Groups

    • CI

      • GPU support is now working for OCIO
    • Diversity & Inclusion

      • Carol: series of meetings with some external university and community participants. Would like to kickstart “D&I Ambassador” program, representative from D&I group to attend every TSC meeting, work to get on agenda. Get a more concrete idea of what that ambassador would mean to each project.

      • Rachel: points made about onboarding are of interest to D&I group, hoping an Ambassador could help with that process. Not just technical infrastructure but also how to make sure that new contributors feel welcome. Also ties in to mentorship initiatives, how do we open up more mentorship / internship opportunities.

      • Larry: having looked at all the people who applied via GSoC, a lot of national and ethnic diversity in the applicants, but very little diversity with respect to gender. May want to seed certain communities about opportunities such as GSoC. Rachel: not necessarily ready to tackle this yet, but considering how to get people in colleges interested in open source, coming up with good ideas based on conversations with university educators. Still early days on those conversations.

    • Python 3

      • Ashley: big question at the moment is around how to help unblock the transition and encourage studios to start moving. DCC vendors are “supporting Python 2 as long as clients require it”, and clients reluctant to move until forced by end of support in commercial DCCs.

      • What does this mean for VFX Reference Platform in terms of commercial DCC versions?

      • Daniel: we now have Python 3 versions in various degrees from all the key vendors.

      • Ashley: the amount of discussion in the group has discussed, have gotten past the initial steps of “what do we want the group to be”, there’s less to discuss since the group is no longer in a startup phase.

    • USD

      • Corey: couple of threads of discussion around self organized standards, find a way to make the WG a forum to present this work (came up in context of BIM / civil engineering work in USD). How does WG organize around that, want to make it clear this is a place for this to happen.

      • Role of USD in the VFX Platform, will deliver on WG minutes from 16-Sept-2020

  • Technical Project Updates

  • Update on candidate projects

    • Datasets

      • John: results from industry survey. WG coming together to put together a potential project for ASWF to hold high quality datasets for testing. Governing Board spoke about it yesterday, putting together a Doodle Poll
    • Collaborative Remote Review

      • Will spin up a WG, some people flagged their interest

      • John: will put together a similar poll for this project

  • Next meeting: 7 October 2020

Action Items (AIs)

Notes

Chat