Re: State of OCIO development re: CPU/GPU mismatches


Sean Looper <sean....@...>
 

Been lurking but glad to see a clearly outlined direction.

Also trying not to be mistook as Sean Cooper. 

Sean Looper

On Sep 12, 2016, at 8:58 PM, Larry Gritz <l...@...> wrote:

Thanks for teeing that up, Sean, I was already intending to wade into this tonight. :-)

It has never been SPI's intention to abandon this project, and we definitely want to continue having a significant role in its continued development. We rely on it as heavily as anybody, so we are highly incentivized to keep it alive. I think it makes sense for us to step up as continued host and overall organizer of the project, but without Jeremy we are certainly going to need a lot of help and leadership from the senior developers elsewhere.

I'm really not qualified to run the project -- I have only passing familiarity with OCIO internals and color science. But I do know a thing or two about the proper care and feeding of open source projects, and it makes sense for me as SPI's software architect to help shepherd the process. So I'm prepared to help or kibbitz as needed and to the degree that I'm able. I also have admin privileges on the repo, so if there are necessary tasks such as granting others push privileges and so on, I can help with that backlog.

If anybody is interested in my opinion:

I don't believe in discrete "releases" (in the sense of something being developed offline and occasionally dropped in big hunks into open source).  The successful projects seem to be the ones where the actual day-to-day development is done out in the open on the master branch, with the biggest contributors themselves using the top-of-tree for their own productions. It's ok to have tagged releases or stable branches for the sake of users or vendors who want to lock down to a point where the software and APIs are known to be stable. But it's the user who should move forward in large discrete steps, not the developers. This is how we do it for OIIO and OSL -- in both cases, SPI's production tools build straight from master, we don't use a single line of code that's not on the public GitHub and going through public code review/pull request, and there is no design discussion other than on the public mail list. 

I think the first order of business is triage:

* Revisit all the outstanding pull requests: which are still relevant, which are important, which have been adequately code-reviewed and tested. They should be ranked in terms of how important/helpful they would be to merge. (You can't do them all at once; there has to be some order in which they are rebased, tested, and merged.)
* Revisit all the outstanding issues, close the ones irrelevant, mark duplicates, assess the difficulty of fixing them, and identify if any are potentially addressed by the pull requests.
* Identify people who have made significant improvements in private branches and encourage them to turn them into proper pull requests, so they can be code reviewed and integrated into the master.

Then find a reasonable number of PRs and fixes that can be more or less immediately merged, do so, and tag/release. It doesn't need to be an ambitious release, but releasing something will help put a stake in the ground declaring this as a living project.

I also think it might be helpful to invest some time up front in setting up TravisCI/Appveyor continuous integration to build with several platform configurations and run tests (please tell me OCIO has a testsuite?). I've done this for OIIO and OSL, and it's a tremendous time-saver to know that any pull requests being considered are known not to break the build or existing functionality; this will greatly streamline the processing of a long series of overdue pull requests (which, even if we presume each one works correctly when applied on the TOT master, should NOT be assumed to work when applied one after the other).

Does this sound like a reasonable path forward?

-- lg


On Sep 12, 2016, at 7:16 PM, Sean Cooper <se...@...> wrote:

Larry Gritz has and will be following the OCIO activity, but from what I understand isn't looking to be directly responsible for its progress. Erik Strauss has / will also be watching it's development. Apart from that, it'll be me actively working with all of you.

I agree on the open development. I think it would be beneficial at this point to sort through existing pull requests and issues, see what's ready to go, and what is still relevant after 2 years. Perhaps wrapping these into a dev branch?

On Mon, Sep 12, 2016 at 6:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@...


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

Join ocio-dev@lists.aswf.io to automatically receive all group messages.