[epic] v1.0.0 Proposed release blockers

[joelanford]

Approved Release Blockers

• [x] https://github.com/operator-framework/operator-controller/issues/921
• [ ] https://github.com/operator-framework/operator-controller/issues/944
• [ ] https://github.com/operator-framework/operator-controller/issues/923
• [x] https://github.com/operator-framework/catalogd/issues/288

Proposed Release Blockers

• [x] #893
• [ ] https://github.com/operator-framework/operator-controller/issues/987
• [ ] #869
• [ ] PR https://github.com/operator-framework/operator-controller/pull/970
• [ ] https://github.com/operator-framework/operator-controller/issues/994

Non-blockers

• [ ] https://github.com/operator-framework/operator-controller/issues/945
• [ ] https://github.com/operator-framework/operator-controller/issues/955
• [x] https://github.com/operator-framework/operator-controller/issues/914
• [ ] https://github.com/operator-framework/operator-controller/issues/967
• [ ] #879

Resolved

• [x] https://github.com/operator-framework/operator-controller/issues/961

[joelanford]

I took the liberty of moving a few of the release blockers to non-release blockers:

1. 945 is an e2e test. There is no indication today that the actual behavior related to reconciling ClusterExtensions due to ClusterCatalog changes is incorrect.

2. 955 does not change end-user facing APIs for functionality. It can be fixed after 1.0.0.

3. 914 is a performance and UX issue, not an API or functionality change, so we can technically wait until after 1.0.0 to fix it. But I also still think that going out with this as a known issue would be a signal to users that we are unnecessarily rushing 1.0.0.

[tmshort]

Added #987, #879, #893. #869 as proposed release blockers

[tmshort]

And added #970 as a proposed release blocker.

[joelanford]

I don't think #869 is a release blocker because it is not a functional or API change. It is an optimization for reducing disk read/write/usage.