# 7/25/2019

### Attending:

* Cary Phillips
* Peter Hillman
* Kimball Thurston
* Larry Gritz
* Christina Tempelaar-Lietz
* Rod Bogart
* Emily Olin

### Agenda

* Prep for SIGGRAPH BoF. Draft of slides is here:
  https://docs.google.com/presentation/d/1mxzp6jn2zuHAyahzwhocwRTpoenNqO-LEvPUvS7gDww/edit?usp=sharing

* Prep for 2.4 release.

### Discussion

* When the repo moves to the ASWF organization, we'll make it
  "OpenEXR". Capitalization isn't consistent across ASWF projects, but
  we prefer it this over "openexr".

* SIGGRAPH BoF prep:

  * Preable about the ASWF and recent progress should be brief; most
    time should be reserved for the discussion. And the topics should
    be presented as "community issues", raised by the community for
    discussion within the community, facilitated by the TSC. These are
    not plans to be executed by the TSC, the TSC is merely a
    gatekeeper.

  * Imath proposal: 

    * Half should have #define/#ifdef so that when included with CUDA half.h, the first one wins.
    
  * Peter's part ordering standard/documentation should be a proposal to go into a 3.0 release. 

  * The need for a "tiny" EXR implementation? Because there are
    numerous divergent ones out there; rumored examples at Apple,
    Intel, and a part of ffmpeg, instigated by several factors:
 
    1. People building OpenEXR get to the b44 log table build stage and say, WTF?!?

    2. There is no option to build the library without exceptions, a
       deal-breaker for platforms/compilers that don't support
       exceptions, and a turn-off for many others.

    3. You need a PhD in CMake to get it to build.

    4. For many people, the write-it-yourself threshold is quite low.

  * There are people who choose not to use the library. We should
    listen to them, even if they're not in the VFX industry. OpenEXR
    is widely used; we have an obligation to be stewards outside of
    just the film industry.

* Release prep:

  * Windows build is not quite working. There are still problems with boost.

  * Windows tests are failing.

* Issues:

  * #445 should not go into 2.4. It needs a more thorough analysis, and wider testing.