)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":38368,"name":"Christian Ohanaja","display_name":"Christian Ohanaja","email":"cohanaja@nvidia.com","username":"cohanaja"},"change_message_id":"b46d895f13547ef438acbd8a92206e1ef0130998","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2e9e3bb3_2fc9750e","updated":"2026-08-17 19:13:20.000000000","message":"Fan of the change, slightly wary on gating functionality behind versioning.... although I understand why it\u0027s needed in this case. Do we have a rough timestamp on when 1.9.0 is releasing?","commit_id":"a145ed9d2726b588c828cab5837f3283f446f808"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"fe35f35cdaf180e1390086b13b52eac247ad2b34","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"fba76f60_3d05c95c","in_reply_to":"2e9e3bb3_2fc9750e","updated":"2026-08-18 01:32:42.000000000","message":"\u003e Do we have a rough timestamp on when 1.9.0 is releasing?\n\nWe have full control over that, but presumably not until after https://review.opendev.org/c/openstack/pyeclib/+/1000979 lands ;-)","commit_id":"a145ed9d2726b588c828cab5837f3283f446f808"},{"author":{"_account_id":38368,"name":"Christian Ohanaja","display_name":"Christian Ohanaja","email":"cohanaja@nvidia.com","username":"cohanaja"},"change_message_id":"449b0c442aae8e758ed356995099d638cc235423","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a3a16702_53b2f63c","in_reply_to":"fba76f60_3d05c95c","updated":"2026-08-18 23:02:50.000000000","message":"good thing we are vertically integrated!\n\nI thought a bit more on it and I was wondering why we don\u0027t just believe in the cluster operators and their ability to manage their dependency versions and set their swift config based on it?\n\nThe setting is default off, so...\n\nIn the worst case (hopefully doesn\u0027t happen), where the operator for some reason turns ON decode_offload with the incorrect dep versions required because they\u0027re really excited for the performance gains, the biggest/only? downside is that each thread holds the GIL similar to how it was already before but with the added overhead of tpool.execute work. \n\nNothing catastrophic I think, but admittedly less UX ergonomic than automatically checking + disabling based on version. 🫠\n\nand in the happy case, operators get the perf boost + we keep existing configuration precedence + we get to avoid doing one-off package versioning checks in the future\n\nI think if that makes sense we could strip all the version checking logic + tests from the patch.","commit_id":"a145ed9d2726b588c828cab5837f3283f446f808"}]}