# 3/25/2021

### Attending:

* Cary Phillips
* Christina Tempelaar-Lietz
* Eskill Steenberg
* Joseph Goldstone
* Kimball Thurston
* Larry Gritz
* Nick Porcino
* Serio Roja

### Discussion:

* nvcc 10.1 errors on the detector templates in ImathTypeTraits.h. Not
  sure what's going on, but #if-ing them out is sufficient.

* Get final changes in for the 3.0 release over the weekend, then cut
  a new beta release, say, Monday. Then let it sit unchanged for
  several days until April 1, when that exact code becomes the
  release.

* We need better coordination with the VES committee regarding release
  schedules and vendor demands.

* ImfAttribute symbol warnings: not propagating a setting? Export is
  stubbed out for Windows, that may be the issue. Nick will investigate.

* Setting the tag on Imath that openexr pulls to build. Once Imath 3.0
  is officially released, set the RB-3.0 branch of OpenEXR to pull
  from that. But leave openexr/master pulling from Imath/master. That
  way, we have some CI pulling on the master branch from another repo.

* CLA status: Weta and Epic still in progress.

* "Release” branch: The goal is that the thing called "release" is
  always the latest. Have a branch called "release" and update it to
  point to the release tag after a release. It's not a branch to merge
  into, and doesn't have to be fast-forwarded, just set to the proper
  commit.

* Release notes technique: Larry: I heavily edit.

* Windows Deadlocking: NickP says it's the hopper, haven’t
  forgotten. The person who submitted gave a minimal repo case. It’s
  on shutdown. Intermittent and only on Windows. Deadlocks on
  shutdown. Possible solution: dllmain? Some users wish OpenEXR didn't
  have custom threadpool, just use TBB.
  
* Some users keep long-lived cmake caches. We’ve baked the namespaces
  into cmake variables but namespaces update on every minor release.
  Should the default be a empty string, require setting?

  * Larry: the build/install instructions should be: “Start with 'rm
    build'” so there's no chance old cmake caches mess up the build
    for users who aren't cmake experts.
  
  * And CMake 3.13 has -S/-B options: cmake -B my/build/dir -S my/src/dir

* gh command line tool is your friend. https://cli.github.com/

* Joseph: The SMPTE committee working on the 5-year revision of the
  ACES Container has taken a careful look at its charter and thinks
  the group should limit itself to color-related metadata changes in
  their efforts. Back in 2012, when we created the original document,
  there was no ASWF, OpenEXR development was effectively dead, and so
  we though we were doing something useful by putting in some
  VFX-supporting attributes into the ACES Container
  specification. That utility was never realized because no one moved
  those attributes into the reference implementation, though.

  The PR that I had put in to reconcile the two worlds, implementing
  in ImfStandardAttributes.{h, cpp} and the accompanying unit test,
  doesn’t make sense now. I do think there is utility in moving SOME
  of that stuff into the reference implementation, but I think the
  semantics and the names and the interrelationships need to be
  defined by VFX professionals.

  Certainly we have a lot of VFX professionals in the OpenEXR TSC, but
  many of us are constrained by our employers in what we can say about
  useful lens metadata. I have proposed to the VES, in email, the idea
  that they do it, or rather, that the executives who form the VES
  Technical Committee designate people at their companies who have the
  expertise, and that (crucially) they give them permission to speak
  up. Not to divulge their most advanced techniques, but to at least
  give feedback upon what I propose to move over from the ACES
  container spec. They agreed to hear me out, and I am presenting
  during their meeting on the 8th, a week and a half from now.

