December 13, 2021

Host: Michael Dolan

Attendees:

  • Rémi Achard (TSC) - DNEG

  • Mark Boorer (TSC) - Industrial Light & Magic

  • Mei Chu (TSC) - Sony Pictures Imageworks

  • Sean Cooper (TSC ACES TAC Rep) - ARRI

  • Michael Dolan (TSC Chair) - Epic Games

  • Patrick Hodoul (TSC) - Autodesk

  • John Mertic - Academy Software Foundation / Linux Foundation

  • Carol Payne (TSC) - Netflix

  • Mark Titchener (TSC) - Foundry

  • Carl Rand (TSC) - Weta Digital

  • Doug Walker (TSC Chief Architect) - Autodesk

  • Kevin Wheatley (TSC) - Framestore

  • Sergio Rojas

Apologies:

  • Kevin Wheatley

OCIO TSC Meeting Notes

  • 2.1.1 is up-to-date (only waiting for the 2 MSL pull requests):
    • Patrick: Ready to make release. Merged most code, only Metal work remaining to merge in RB-2.1. Still some pending questions, but can be follow up. How will we have CI build with Metal? Can be in later PR. Unit tests are built using OpenGL context with Metal backend (oglapphelpers). What will happen when OpenGL is dropped from macOS? Not part of core, but good to discuss.
    • Doug: Right now if you want to use Metal in OCIO, you don't need OpenGL, but for unit tests and ociodisplay, you do need it.
  • 2.0.3 is up-to-date and ready to go:
    • Patrick: Everything is merged.  There are some important bug fixes.
    • Michael: Should probably do 2.0.3 release first.
    • Doug: Yes, that will result in ideal release order on GitHub releases page, with 2.1.1 being at top.
    • Patrick: Not all users are following VFX reference platform, so valuable to release both versions.
    • Michael: Think it's worth releasing even if nobody uses it.
    • Doug: Good for fixing existing implementation. Can drop in new version.
    • Patrick: Will need to make some PRs to change versions, etc.
  • Coding style enforced with clang-format
    • Patrick: Major PRs from external contributors going very well, adding great new features. Really happy. An ongoing challenge is code style. Some try to follow existing style, others are less careful. It bloats code review making style comments. Creates a lot of discussion for less interesting parts of code changes. What can we do? Solution would be to use clang-format. More and more projects use it. OCIO doesn't follow standard coding style. Time to resume that discussion.
    • Michael: OIIO started using it a couple years back. Larry created style for existing code and blocked certain sections from clang-format where the current format was important. Had a few big PRs to update most files. I agree this would be good to do for OCIO. Can setup CI to fail if code style isn't valid, and then contributor can just run clang-format locally to fix it and add another commit.
    • Patrick: Could also use it for new code, and leave existing for now.
    • Michael: It's a good time to implement it. No major features on the horizon at the moment and wrapping up the latest round of releases. We can discuss in the new year when more of the TSC is present.
    • Doug: Thank you Patrick for shepherding contributions through the process.
  • Items for next meeting agenda:
    • NOTE: All OCIO meetings are canceled until new year
  • No labels