CY2022 Finalized

[Nick Cannon]

CY2022 has just been finalized. Congratulations to the OpenColorIO team for releasing 2.1 on schedule yesterday which means there was no need to revert OCIO or ACES versions.

A minor change from the most recent Draft is that Python was updated from 3.9.x to 3.9.1-3.9.latest due to a pybind11 issue with the 3.9.0 release.

The only outstanding issue is the pending OpenVDB 9 release with support for OpenEXR 3 which is due by November 1st.

In the event there are any late requests for changes then we will bring them to this group for feedback and only adopt them if there are no strong objections.

We have also added a Support Guidance section to https://vfxplatform.com which states:

• Providers of software libraries focused on VFX and animation content creation should aim to support their releases for the current calendar year and the three preceding years. Studios and end users should have no expectation of support for older libraries.
• The VFX Reference Platform strongly recommends open source project maintainers provide a level of support described by the FLOSS Best Practices Criteria, which is already a requirement for all Academy Software Foundation projects.

We hope this advisory guidance will go some way to aligning expectations around support.

As always, thank you for the great input, feedback, and support this year.

Nick

[Rob Bredow]

Congratulations. A great milestone.

Thank you to Nick and everyone of you who volunteers so much time to contribute to this important effort. Much appreciated!

Rob

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/068df155-9c9e-4898-92fd-da0d7dc9ff78n%40googlegroups.com.

[Larry Gritz]

Woo-hoo, congrats! It's a good list this year.

• Providers of software libraries focused on VFX and animation content creation should aim to support their releases for the current calendar year and the three preceding years. Studios and end users should have no expectation of support for older libraries.

I can think of a few interpretations of this, and would appreciate a bit more clarification of people's expectations.

For simplicity, let's consider the current version of OurPackage to be 2022 (since you require the "2022" packages to be already released now), and thus the three preceding years include back to 2019. We also have the "environments" (toolchain and dependencies) implied by the rest of VFX Platform 2022, and back to VP2019.

I think that your guidance minimally means: we should backport and release new OurPackage-2019 patches that fix any truly critical bugs and security fixes for which CVEs have been assigned.

But I wonder which, if any, of the following more generous interpretations might be expected:

* Should ordinary user bug reports or questions be investigated and fixes backported to OurPackage2019? Or is it assumed that the "support" for 2019 packages is limited to critical fixes only, and for more than that, users are be advised to upgrade?

* Should OurPackage2019 continue to be maintained so it builds and runs in newer environments, including up to current/VP2022 toolchain?

* Should we try to ensure that the current version, OurPackage2022, is able to build/run in the environment of VP2019?

As a more concrete example using familiar packages: Are people really expecting active user support and bug fixes to be backpatched into OpenEXR 2.3, OpenColorIO 1.1, or OpenVDB 6 (the 2019 releases)? When phrased this way, it seems unlikely that those dev teams are realistically able to provide that level of support to such old versions. 

I don't think there are necessarily right or wrong answers to these questions. I'm just curious about what people's expectations and needs are, in practice. I don't know if those expectations differ for commercial/closed apps versus open source projects, nor if they differ for projects that are themselves on the VP list versus those that aren't, but swim in the same waters.

--

Larry Gritz

l...@larrygritz.com

[Robert Fanner]

Hi Larry,

Thanks for the excellent questions - they feel like they might make the beginning of a great FAQ section.

Your minimal interpretation is on point. Investment needs to go where it matters and the technologies need to have a forward-looking slant from the development and maintenance perspective.

"Support" can get complicated quickly, so our initial guidance here is intentionally broad and somewhat ambiguous on the basis that some alignment on expectation is better than none at all.

The thinking underpinning the support guidance is that tying it to previously published VFX Platform CYs helps to capture the specific versions of software used in conjunction with each other (a well worn groove for adoption, support and runtime environment for these, if you will). To a degree, it also implicitly captures the extant (complex) support considerations that library maintainers have evolved over time to facilitate supporting libraries for typical show durations.

Ultimately the hope is to capture things the industry is already doing/striving to do, and not to introduce onerous new burdens on maintainers.

With this in mind, here is my take on the questions you posed in slightly more detail:

I think that your guidance minimally means: we should backport and release new OurPackage-2019 patches that fix any truly critical bugs and security fixes for which CVEs have been assigned.

That's a great summary.

* Should ordinary user bug reports or questions be investigated and fixes backported to OurPackage2019? Or is it assumed that the "support" for 2019 packages is limited to critical fixes only, and for more than that, users are be advised to upgrade?

Extant practices means the latter is appropriate. Studios on longer shows tend to lock down dependencies for stability, and would likely only roll out updates for the most critical issues. Commercial app vendors tend to provide ~2 years support, and are similarly unlikely to adopt and ship patches in older dependencies for anything that isn't absolutely critical.

* Should OurPackage2019 continue to be maintained so it builds and runs in newer environments, including up to current/VP2022 toolchain?

From an external support perspective, a show locked on VFX RP 2019 and the implied OS and vendor environment is unlikely to jump to a VFX RP 2022 environment. Moreso if we look ahead at VFX RP 2023.

That said, library maintainers may find it helpful to have leeway to ease internal library development, but the degree to which this is feasible depends on library design (e.g. C++ language features used, OS library APIs used).

While unlikely to be the case, as an extreme example, if a VFX2022 package couldn't even begin to be compiled vs a VFX2023 toolchain (for the sake of the argument, RHEL 8 as OS) during porting work, that would be rather awkward.

* Should we try to ensure that the current version, OurPackage2022, is able to build/run in the environment of VP2019?

Locked shows and vendor app support makes this less likely to be something valuable to strive for in terms of support. Bridging the string ABI divide tentatively pending in VFX2023 would certainly make this sort of upstream swimming hard!

As a more concrete example using familiar packages: Are people really expecting active user support and bug fixes to be backpatched into OpenEXR 2.3, OpenColorIO 1.1, or OpenVDB 6 (the 2019 releases)? When phrased this way, it seems unlikely that those dev teams are realistically able to provide that level of support to such old versions.

The hope is that with the minimalist interpretation the span of years might be achievable, but we're very happy to take input on the feasibility of this ambition, and it does need to line up with existing practices.

Best regards,
Rob Fanner

[Larry Gritz]

Thanks for the follow-up, I do think that clarifies a lot.

I think that my de facto practices fall somewhere in the middle of what you've described in your clarification.

I tend to actively support users and liberally backport fixes (and "safe" enhancements that don't break compatibility) for ONE previous year's release family. Each year earlier has increasingly narrow circumstances in which I'm willing to patch it. In practice, it's rare that I patch releases that are > 1 year old, and I can't remember the last time I patched a release that was > 2 years old. (This aligns with your observation that anybody using a non-current version is probably intentionally locked down and doesn't want to make any changes to software that appears to work for them.)

However, "I don't patch releases prior to last year's" is accompanied by "but I do make sure that this year's release, which has the fixes you need, can build and run in every VP ecosystem back to 2019." So I think that a high degree of source code backwards-compatibility and careful CI testing against older toolchains can be a substitute for directly supporting releases going back several years.

It is for that reason that I tend to be so concerned with exactly how many years back of an ecosystem I should continue to support. The 3 year guidance is very helpful in providing a concrete hard limit as an answer to this question.

-- lg

--

Larry Gritz

l...@larrygritz.com

[Robert Fanner]

Hi Larry,

However, "I don't patch releases prior to last year's" is accompanied by "but I do make sure that this year's release, which has the fixes you need, can build and run in every VP ecosystem back to 2019." So I think that a high degree of source code backwards-compatibility and careful CI testing against older toolchains can be a substitute for directly supporting releases going back several years.

Thanks for outlining your support approach - that makes perfect sense. Providing great backward compatibility and ecosystem support would be in line with the intent of the proposed guidance.

Kind regards,
Rob

[Larry Gritz]

Quite coincidentally, I ran across this talk yesterday: https://www.youtube.com/watch?v=HeeoTE9jLjM

I thought this was interesting. The talk is about the Linux kernel, but I think applies more broadly to our ecosystem.

Summary: Only some CVEs are "real" security issues, only some real security issues get CVEs, and many ordinary bug fixes are not recognized as being security related at all (even if they are). Moreover, many patches are only secure or correct when in the presence of other nearby patches. The safe thing for downstreamers to do is to stay fully up to date with LTS releases of software in full (i.e. get all known fixes!), and you should consider "old release + cherry picked patches for CVEs only" to be insecure by definition.

It raises the question about whether we are fooling ourselves by back-porting primarily CVEs to 3 prior years of releases. If you buy into this speaker's thesis, not only would this be a false sense of security by only selectively applying patches, but those releases may be considerably less secure because those patches are "out of context" or lacking other patches that they subtly depend on.

I'm not necessarily proposing this, but merely putting it out as a point of discussion.

Some library releases break backwards compatibility, and thus are very difficult and unwise for a DCC to upgrade for a mid-year patch (concrete example: OpenEXR 2.5 -> 3.0). Other library releases can seamlessly be upgraded with no source code changes to the DCC (concrete example: OpenEXR 2.3 -> 2.4 -> 2.5, and also 3.0 -> 3.1). In fact, the library authors may strongly feel that upgrading Maya+exr2.4.0 to Maya+exr2.5 mid-year should be a snap and on the whole LESS risky for customers than patching only to Maya+exr2.4.1.

So another support approach for libraries that's worth discussing might look like the following:

* Library is really careful about not breaking source compatibility year-to-year, but does so only occasionally, and also ensures that the current release builds and runs correctly against the VFX Platform toolchain and dependencies up to 3 years back (or back to the last compatibility break, whichever is more recent).

* The last release before a break in source back-compatibility is considered a LTS (long term support) release and will get, to the greatest extent possible, all reasonable bug fixes and safe improvements for 3 years. The "current" release also gets full bug fixes, of course.

* Non-LTS releases are "as-is" -- that is, for releases that can be seamlessly upgraded to the next major release with only a recompile and not edits of downstream source code, they will not be routinely maintained after the next release, and instead the advice to downstream consumers is to fully upgrade to the latest maintained source-compatible release.

So just to make this clear, let us consider OpenEXR. The current endorsed practice is: New development happens in future/3.2, full support to 3.1, and fixes that we think are related to CVEs (and sometimes other critical fixes) are backported to 3.0, 2.5, and 2.4 (with rapidly increasing PITA for developers the farther we get down that list).

An alternate approach might be: New dev in future-3.2, "full support" to current release 3.1 and presumed LTS release 2.5, no support to 2.4 and 3.0 (which should be upgraded at earliest opportunity to 2.5 and 3.1, respectively, to pick up comprehensive fixes). In some ways, this is just pushing the peas around the plate -- it demands more thorough support for 2.5 and 3.1, but eliminates support for 2.4 and 3.0. But that might result in the releases that are supported becoming more secure and stable than if we spend the same resources half-assedly patching so many, older, releases.

This might not be the right approach for all libraries. It probably depends on how often they have compatibility-breaking releases. But it may be worth considering as an additional, optional, strategy that is endorsed by VP. So in this alternate universe, VP might recommend that libraries either (a) support up to 3 prior years but impose no limits on year-to-year compatibility, OR (b) only support LTS up to 3 years back, but have strong guarantees for non-LTS releases to be trivially upgradable to either an LTS or the current release.

Something to ponder?

-- lg

-- 
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/75B3832A-1FD8-442D-98DA-0E5435952558%40larrygritz.com.

--

Larry Gritz

l...@larrygritz.com