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?
--
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.
--
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.
