-
Notifications
You must be signed in to change notification settings - Fork 626
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Cary Phillips <cary@ilm.com>
- Loading branch information
Showing
1 changed file
with
69 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
# 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. | ||
|