March 7, 2022

Host: Carol Payne

Secretary: 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) - Epic Games

  • Patrick Hodoul (TSC) - Autodesk

  • John Mertic - Academy Software Foundation / Linux Foundation

  • Carol Payne (TSC Chair) - Netflix

  • Mark Titchener (TSC) - Foundry

  • Carl Rand (TSC) - Weta Digital

  • Doug Walker (TSC Chief Architect) - Autodesk

  • Kevin Wheatley (TSC) - Framestore

  • Thomas Mansencal - Weta Digital
  • Sergio Rojas

OCIO TSC Meeting Notes

  • 2.1.2 release fixing the Python wheels in order to release Colour:
    • Thomas: Released colour without OCIO being explicit dependency, since waiting on wheel for macOS ARM builds, which were deleted from PyPI.
    • Patrick: So it's better to keep broken wheel instead of removing it?
    • Thomas: Yes. Otherwise it's a dependency pulled while installing, which would have failed colour.
    • Doug: So would have failed later instead of up-front if we kept it
    • Thomas: Yes, which would have been ok since OCIO is optional dependency.
    • Patrick: Is keeping bad build a rule, or just a preference?
    • Michael: In PyPI you can hide a full release, so it isn't found unless requested explicitly, but for specific wheel could only delete it.
    • Rémi: Reason for deleting bad wheel was for new users, to avoid issues, but for existing users like colour, makes sense not to delete it. Thought pip would fallback onto source install, which didn't work.
    • Kevin: Always go forwards. If you can make new wheel that would be preferred.
    • Doug: With ARM, assuming other packages are being installed in Rosetta mode?
    • Thomas: Things are working as expected. There were issues last year, but working fine now,
    • Doug: If someone pip installs ocio in Rosetta terminal, would that work?
    • Thomas: Yes, should grab the correct version.
  • Release branch support policy:
    • Rémi: For 2.0 release branch Python bindings, there is still some missing stuff (virtual displays and shared views). Are we still supporting that release branch? Should we backport fixes? Do we still support VFX ref 2021?
    • Patrick: Question of how do we want to support it. Try to backport bug fixes. Can be complex. Previous thought was to only backport major color processing bug fixes, but not CMake, etc. Idea there would be to move to the next version. If you have to recompile anyway, why not move, since It's backward compatible. Python is a good point though. Need to see what we need to do.
    • Carol: I agree in principle, but there will be some lag with people using older versions of DCCs, which are using older OCIO versions. Nuke is using 2,0 for example.
    • Mark T: VFX ref platform related too. Working to get next major release to 2.1. There is a lag though, yes, both in development, and in studio adopting the new version for a show.
    • Carol: Could be opportunity to skip Nuke version.
    • Kevin: We carefully switched to 13.1, bypassing 13.  Did the same for Mari. That's not our normal practice, which would be to be more cautious, and having a version around for a couple years. Wouldn't assume a vendor would be able to do a fix for something that far into the process. If we're in a show, not going to change the version, just going to live with the bugs.
    • Carol: Python bindings bug fixes may fall into that area where it would be good to backport.
    • Doug: Seems to be a case by case thing. Not sure we have a rule on it. For sure we will fix color processing bugs, but some other things may be different. If a fix is requested we would raise the priority.
    • Patrick: We can add things to Python bindings, but not to core library. Can be raised at TSC to discuss.
    • Rémi: Case by case sounds good.
    • Mark B: Does that include create editable copy?
    • Rémi: That's different patch, but can add it.
    • Kevin: That's blocking some of our teams from upgrading to v2
    • Doug: For people who want those features, which are in 2.1.1. What is the use case? 
    • Mark B: For me, standalone uses. Studio shifting to Python 3, and the current Python code I launch with OCIO can't be used since it's missing that functionality.
    • Rémi: The patch is not released yet
    • Kevin: Not a show stopper, but held off upgrading.
  • Plan for the next release:
    • Michael: Sounds like we are ready for a patch release with the Python copy fix.
    • Carol: If everyone is ok with that one, can discuss more at next TSC whether standard release cadence is helpful. Deadlines can be helpful, but don't want to schedule for the sake of schedule.
    • Doug: VFX ref platform will likely impose a cutoff date for 2023, which would be when we release new features.
    • Michael: For patch release, can do them as often as weekly if needed. How involved is a patch release Patrick?
    • Patrick: Not difficult.
    • Doug: Would help to have issue for each version where we list the PRs to add to each release. That would help on our side, rather than deciding on our end which fixes get released.
    • Patrick: Or could be a label
    • Carol: Not all users can create labels. We could add them if needed
    • Doug: Good point.
    • Kevin: Could use projects as well
    • Carol: Will talk with Thomas about best way to implement.
  • Baking LUTs (CTF) produce different results on different platforms, is that ok (#1598)?:
    • Doug responded in PR about precision question
    • Rémi: The concern was that if you generate CTF with LUTs, slight difference per platform. Need to have some round trip. I fixed that in PR and added tests.
  • Google Summer of Code:
    • Carol: ASWF got accepted to GSoC as mentoring organization. First thing we need to do is make sure good first issues are in a good state. Can add new first issues also. Applicants need to submit a PR before being considered. Can talk more in Slack. In ASWF Slack there is a gsoc-2022 channel. That's where contributors will be joining first.
    • Michael: I think there is a gsoc Slack channel in our workspace also, from last time.
    • Thomas: Are there any project ideas yet?
    • Carol: https://tac.aswf.io/gsoc/2022.html
  • ASWF Technical writing resource:
    • Carol: There are discussions happening at TAC about technical writing resource for projects. Need to provide details on how we would use that resource, to provide to board for budgeting.
    • Michael: UX guidelines would be one area we could use help with
    • Thomas: Also Google season of docs which we could participate in.
    • Carol: We should probably do both.
  • Slack instance discussion:
    • Carol: John Mertic asked about migrating to overall ASWF Slack instance. Mostly because ASWF pays for Slack, so keep message history, and get other paid features. There's a lot to this. Is it worth the change?
    • Michael: I don't think there are nested workspaces, but could have multiple "ocio-" prefixed Slack channels. 
    • Doug: Will Slack migrate it?
    • Carol: I think there are ways to support it, but not sure if they have a migration tool.
    • Thomas: You can't share channels between free and enterprise accounts, but maybe they have tools for going to paid instance? Not sure.
    • Carol: ASWF didn't qualify for non-profit, so they pay. 
    • Mei: Think there slack channels that are on multiple workspaces, and could sync.
    • Thomas: I think they only work for enterprise Slack. Since OCIO instance is free, not sure. We should check. Owner can export Slack content on regular basis.
    • Carol: That's one benefit of having our own instance, is we have dedicated history.
    • Mark B: There are 10 admins in our Slack workspace currently who can export. No objection to moving it, since it would reduce Slack workspaces.
    • Carol: Important discussions are happening in Slack, and in our case we move decisions to GitHub to preserve history, but that may lack context.
    • Patrick: Best to have discussion in issue or pull request. Difficult to find old conversations in Slack. Important conversations should be moved to GitHub.
    • Thomas: Moving is painful for community. People are there already.
    • Remi: Is ASWF Slack public?
    • Carol: Yes
    • Michael: If we had to move, we could likely just move a few channels. Only a few get a lot of traffic.
  • Start thinking about SIGGRAPH - BoF?
    • Carol: Was thinking that it might be good to do more user focused BoF in addition to open source days. Could ask for topics from users.
    • Kevin: Yes, needs to be less formal, and more like normal BoF
    • Carol: I'll get deadlines and let everyone know the details
    • Patrick: Good point. Now that OCIO v2 is released, the big challenge will be with users needing to try it. Not color scientist, but users interacting with it in DCCs. Configs, etc. Less library technical developer, more user focused.
    • Carol: Config and UX working groups are good topics
    • Patrick: Examples for new users and for experienced users. Customizing configs, etc.
    • Kevin: Would be interested in seeing what other people would like OCIO to do. Have ideas, but different point of view from beginning user.
  • Daylight savings (again)
    • Doug: Next weekend in North America
    • Michael: Mostly an issue for the working groups, with time zone changes being offset
    • Thomas: Good to wait until all time zones have switched
    • Carol: Let us know if a meeting time needs to be adjusted
  • Items for next meeting agenda:
    • Carol: Will follow up with John Mertic on Slack and can discuss again next time.
  • No labels