)]}'
{".zuul.yaml":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"a0f3c75bb18f8db72beb8896fd5bc9a42d276e14","unresolved":true,"context_lines":[{"line_number":54,"context_line":"    # Skip wheel-testing for (pre-)release pipelines -- the gate job"},{"line_number":55,"context_line":"    # should have caught any problems so at that point, we\u0027re just"},{"line_number":56,"context_line":"    # wasting time and CPU cycles while increasing the likelihood of"},{"line_number":57,"context_line":"    # a release failure"},{"line_number":58,"context_line":"    pre-release:"},{"line_number":59,"context_line":"      jobs:"},{"line_number":60,"context_line":"        - pyeclib-build-glibc-wheels:"}],"source_content_type":"text/x-yaml","patch_set":12,"id":"d2e84d62_d8129ba4","line":57,"updated":"2026-10-26 21:40:10.000000000","message":"Well... there\u0027s a race between when the gate buildset runs and the release buildset does -- in that time, we might pick up a new (breaking) setuptools release, for example...\n\nMaybe we should just always do the testing. I forget how much of the release buildset may run while the wheel-building jobs fail -- at the very least, we know the `release-openstack-python` job won\u0027t, so I *think* we should be fine to just re-enqueue in case of failure? (Or, land a patch to avoid the busted setuptools version, and cut a fresh tag.)","commit_id":"08339b9f8b54a4799b79368c9768e9ebc27aec6a"}],"/COMMIT_MSG":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"c663d195c8b39ec9206fc8ef1ddf53ac25d333a4","unresolved":true,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Actually test the wheels we build"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Increase the wheel-building timeouts now that the jobs perform more work."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Note that this finally has us test with free-threaded python builds!"},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":8,"id":"2ca5067e_29d063a6","line":9,"updated":"2026-10-12 00:49:34.000000000","message":"So that\u0027s an obvious downside: the wheel-building jobs have roughly tripled in duration. We could probably do *something* to help, like do the testing in parallel dependent jobs with just one or two wheels per job -- but then we\u0027d have each of the dependent jobs downloading (at least one) quay.io image in addition to all the other separate-job overhead...\n\nMaybe instead of having to manually set `test_wheel: false` for the release jobs, we have it be dynamic? Only test wheels if `pyproject.toml` was touched (and there\u0027s a change ID), that way the changelog patches get extra scrutiny, while others have faster turn around?","commit_id":"e813ca84069acf81e946c4f56c6d8a601b07a710"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efc0308e638b4804e554e503f41a261ec6232867","unresolved":true,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Actually test the wheels we build"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Increase the wheel-building timeouts now that the jobs perform more work."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Note that this finally has us test with free-threaded python builds!"},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":8,"id":"9b4ee028_ca933bec","line":9,"in_reply_to":"2ca5067e_29d063a6","updated":"2026-10-14 16:09:08.000000000","message":"Splitting the wheel building into [separate `manylinux`/`musllinux` jobs](https://review.opendev.org/c/openstack/pyeclib/+/1010301) seems to buy us enough buffer that I don\u0027t need to bump up the timeout anymore, but I think this still represents an increased wall-time compared to current master.","commit_id":"e813ca84069acf81e946c4f56c6d8a601b07a710"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"0fd30b61dd30b9ba0d71ed9058e48dff8181abdb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"d1938e5d_6a689f33","updated":"2026-10-20 15:18:31.000000000","message":"recheck\n\nI want to make sure recent setuptools didn\u0027t break py314t builds...","commit_id":"08339b9f8b54a4799b79368c9768e9ebc27aec6a"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"9d1964a8d6ae52e32717d5033493512d17c0c329","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"91914c96_1dfa7d16","updated":"2026-10-20 20:12:20.000000000","message":"recheck\n\nYeah, the recent setuptools releases really highlight for me the importance of testing these wheels... would\u0027ve been annoying to release py314t wheels that (surprise!) didn\u0027t actually work.","commit_id":"08339b9f8b54a4799b79368c9768e9ebc27aec6a"}]}