...
- Rémi as Committer & TSC member:
- Motion approved by TSC since there were no objections raised in GH issue or in TSC mail list thread.
- TODO: Michael will submit PR with needed document changes and add committer permissions to repo.
- Patrick: Reminder that anyone can review and approve PRs, even if approval doesn't count toward merge requirement. Many PRs are in need of review. Important to put time into, even if only reviewing part.
- As there are now two official branches (RB-2.0 & RB-2.1) plus master to manage, the merges, release creations, etc. becomes slower/challenging because of delays on port branches, version change branches, etc.:
- Patrick: These branches should be merged in a few days to clean the pull request list, and let everyone focus on bug fixes, new features, etc.
- Suggestion: Appoint a ‘release manager/coordinator’, and give them the right to merge port branches, version change branches following TSC guidelines.
- These PRs are a lot of noise, but are important. Makes it hard to merge other PRs waiting to merge these. Should appoint someone to manage this.
- Michael: Nominate Patrick or Doug, who have been doing this for the last couple of years anyway.
- Doug: Has become logistical challenge. Want this group to focus on new work. Making sure branches stay in sync is probably not where this group should be spending time.
- Carol: Still need approval to merge? Should we remove that requirement? Think it would clear it up to permanently appoint someone. Unless something crazy is happening, shouldn't need more approval.
- Doug: There is what's in the rules, but then there's also the GH level, and what does GH actions require.
- Michael: Think we can refine branch protection to only need one approver.
- Patrick: We can try to remove the two week requirement for these.
- TODO: Michael will investigate and adjust branch protections as needed.
- Patrick: These branches should be merged in a few days to clean the pull request list, and let everyone focus on bug fixes, new features, etc.
- Discuss about mandatory third-party library version update (eXpat, Yaml, etc):
- Patrick: Some mandatory libraries are now old, leaving known bugs in OCIO.
- Suggestion: Plan to update these libraries for OCIO v2.1.x.
- Michael did PR to move to Imath, but we did not talk about expat, yaml-cpp, and other libs not part of VFX ref platform. Recently someone tried using latest of one of these dependencies and it crashed. What is our plan to update these? Think we should try to update these two libs, and have rule for looking at these regularly.
- Worked with Aloys to update OCIO containers recently for our CI to support OSL and other updates.
- Michael: Two things to note:
- We currently have a nightly CI job which builds OCIO with the latest tag from each upstream project to help track when they break. This workflow has been failing for a while so may be a conflict to resolve.
- Challenge will be supporting range of dependency versions and OCIO_INSTALL_EXT_VERSIONS. Currently the system uses the declared CMake minimum version to automatically install the dependency, which means we either have to increase our minimum supported version to be the preferred version for those who don't provide their own dependencies (which will fail builds if they provide earlier versions), or we need to update the build system to support a default version and a range of supported versions. Think we should do the latter, but will require some work.
- Rémi: Looking at analysis workflow, only building for Linux
- Michael: Did that because of only having VFX ref platform containers for Linux, but we could expand to other platforms. Recommend we split analysis and latest jobs for improved workflow badges and other improvements.
- Rémi: Had issue last week with PRs failing due to Windows failure. Is it ok to migrate wheel CI to analysis instead of CI workflow.
- Patrick: Have limited number of machines, and there's starting to be a lot of traffic. Second this idea.
- TODO: Rémi will move Wheel workflow to nightly process and look into splitting up Analysis workflow.
- Patrick: Some mandatory libraries are now old, leaving known bugs in OCIO.
- OSL 1.15.x & OIIO (starting 2.3.x) are now C++14 minimum, causing various compilation/link issues with OCIO which is C++11 by default:
- Patrick: OSL & OIIO recent versions do not anymore support C++11
- Suggestion: Move OCIO to C++14 by default but keep at least one CI build with C++11
- Michael: C++11 not mentioned in VFX ref platform table anymore. 17 for last two years and 14 since 2018.
- Patrick: Have to be cautious for users who use 11 still.
- Michael: Are we going to try to handle C++ version conflict on our end, or rely on build failure?
- Patrick: Have PR to help with 2.1, but will not handle cases with previous versions.
- Patrick: OSL & OIIO recent versions do not anymore support C++11
- Config working group update:
- Carol: Config working group is hoping to collaborate with the ACES IDT working group on use of CLF for input transforms. We will present at the October 5th IDT meeting and discuss. Cross-over efforts between groups would be helpful. See config WG notes here for more info: 2021-09-14
- Doug: ACES TAC and implementation TAC meetings are this week. Info on ACES central: https://acescentral.com/calendar/
- PRs for review:
- Patrick: Many interesting PRs to review.
- Carol: Super excited to see OCIO v2.0 support in Krita (OpenGL ES PR)
- Patrick: Read study from Mozilla, that when you have many contributors, need to give feedback and support them, not leave them with no answer. On our side need to give attention to their PRs. The study discovered at that time that if we don't provide feedback in a week or less, people tend to forget and go away. Will see if I can find link.
- J: Some other projects have bot to help support committers. Can see when new organization contributes. Might be good to get elevation from those commits.
- Doug: Could elevate them on OCIO Slack. What would be the most effective way of doing that?
- J: On other project, has subject matter experts for topics. Contributors can tag with that topic to get elevation. Also can tag new features. Will look into bot name.
- Patrick: I put comment in Slack on PRs, but can be lost in flow.
- J: Some projects gamify system with points, to encourage continued participation. Can identify trends through GH notifications.
- Build artifacts:
- J: With v2, a feature disparity is providing prebuild prebuilt binaries for plugins (AE/PS/OFX, etc.).
- Michael: We build OFX as part of CI, but don't use the binaries.
- Doug: Brandon Brendan puts AE/PS plugin builds on website: http://fnordware.blogspot.com/2012/05/opencolorio-for-after-effects.html
- Michael: Artifact storage was an initial topic for the ASWF CI working group, but not sure we ever completed that discussion. GH has this new feature which might be interesting to explore: https://github.com/features/packages
- We build binaries constantly, but don't distribute them. Some limitation about supported platforms.
- J: Reasonable to have platform limitations. Would be cool to look into packages feature.
- Rémi: Haven't looked at GH packages yet, but can already upload artifacts for release.
- Zach: Also good to make binaries available for apps. Would help a lot of people.
- Rémi: After publishing PyPI there were questions around apps.
- Michael: Harder to support with apps that require OIIO and OpenGL. Could statically link, but not as simple. Other OCIO apps would be easier to distribute.
- Patrick: Recurring discussion about cyclic dependencies with OIIO, and that ociodisplay has additional dependencies. Good example code, but not ideal for production use.