I think you can add additional pull requests if they are on uniquely named 'topic' branches.

How interesting! - a Truelight Transform...

Only quickly glancing at the code (always dangerous), does this add Truelight as an optional or required dependency?   I agree that this would be better as a plugin, but the runtime implications of plugins vs. optional compile-time functionality are essentially the same. And in this case, as we at SPI do not actively use Truelight, we'll probably want to address the compatibility implications in the short-term.

What's the advantage of using this plugin as opposed to - say - baking it into a baked 3d lut representation at ocio profile generation time?  Would you expect the end user (artist) to dynamically modify the input arguments?   If not, and the transforms inputs are essentially locked for each configuration, what would you think of adding this functionality not to the core library but instead to some of the helper apps?

You obviously implemented this with a workflow in mind, would you elaborate?

My largest compatibility concern is that in the near future, commercial apps will be shipping with native OCIO support. (Yay!)  But, this native support won't compile with Truelight functionality. So we'll essentially have a schism in support, where some people's internal pipelines support ocio+truelight, while the common commercial apps only support ocio-plain.

An OCIO transform plugin API would obviously help to alleviate this issue, but both implements open the pandora's box of profile compatibility issues.  Once plugins (or optional build dependencies) are in use .ocio profiles are no longer generically interchangeable between facilities. You would have to share the profiles, all plugins, potentially plugin source, etc...   And then one would have to consider the licensing aspect as well.

In the current system if you create a valid profile you know it really can be used in any app, on any OS, and easily shared (emailed!) to other vendors.

-- Jeremy