)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"d21674c7ad0895adb8cecb288c9c49b2ed62248b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"489541ca_39b41f10","updated":"2026-06-23 17:35:40.000000000","message":"Agree with clark. I love me some black/ruff and use it in all of my projects. But going back and doing a blanket reformat of existing old code isn\u0027t a thing I\u0027m a fan of. If nothing else, it tends to make things like git blame confusing.","commit_id":"8409235fe91ac2d85bb7ea0aab65aee220310186"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"37fdcd767ee16127fc41caea9487359c33fe8e64","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0faa8b07_93040715","updated":"2026-06-23 16:01:33.000000000","message":"This is the second change in as many days that I have had to review where unrelated formatting changes are getting mixed into proposals for actual changes/fixes. This isn\u0027t a good use of my time. I don\u0027t mind if people apply their personal tooling preferences to new code bases or code bases that they maintain. But I don\u0027t think it is appropriate in cases where the repo has been around for a decade and I\u0027m expected to spend time reviewing these updates.","commit_id":"8409235fe91ac2d85bb7ea0aab65aee220310186"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"cdb32dac9cef097db5e5fc695fd2f68a31aad6c5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"fc88427b_e618f779","in_reply_to":"0faa8b07_93040715","updated":"2026-06-24 10:04:37.000000000","message":"I\u0027m going to take the two of these together since they\u0027re broadly touching on similar points.\n\n\u003e I don\u0027t mind if people apply their personal tooling preferences to new code bases or code bases that they maintain. But I don\u0027t think it is appropriate in cases where the repo has been around for a decade and I\u0027m expected to spend time reviewing these updates.\n\n\u003e Agree with clark. I love me some black/ruff and use it in all of my projects. But going back and doing a blanket reformat of existing old code isn\u0027t a thing I\u0027m a fan of. If nothing else, it tends to make things like git blame confusing.\n\nSo this has hit on a nerve 😂 People keep talking about OpenStack as if it\u0027s some kind of OAP that can\u0027t handle too much change and should be allowed to drift slowly off into obsolescence or something. It\u0027s weird, I don\u0027t get it 😅 We\u0027ve got a good suite of software here, and as much as the rapid changes in ecosystem (looking at you, PyPA) can annoy me, I don\u0027t see why we should ignoring good stuff simply because OpenStack is old. These auto-formatters are one of the good things, as I\u0027ll get to in sec.\n\nOn the technical points raised, `git-blame` isn\u0027t an issue: git has long supported a `.git-blame-ignore-revs` file that (surprise! 😄) can be used to ignore certain revs for `git-blame`. This file is respected by default in forges like GitHub, GitLab and, yes, [Gitea](https://github.com/go-gitea/gitea/issues/26329). `ruff` also isn\u0027t some kind of boutique configuration or tool either: we have `ruff` and we have `black`, and I could have chosen either one and gotten pretty much identical outcomes. I opted for `ruff` simply because it\u0027s *much* faster. We\u0027re not exactly first movers in adopting one of these tools either: I\u0027m aware of at least a few very large, very \"old\" projects that use one or the other:\n\n- SQLAlchemy [uses black](https://github.com/sqlalchemy/sqlalchemy/blob/7ed455b445a030721b2613a64d2aac5a7018b12f/pyproject.toml#L231-L237)\n- [So does Django](https://github.com/django/django/blob/420b4f5b0170d090d3b5b78b5c0d3986743e39db/pyproject.toml#L55-L62)\n- [And Zulip](https://github.com/zulip/zulip/blob/4ee1128433f0661a3dfb433aea5d6c03febd6d2c/pyproject.toml#L365-L373)\n- CPython uses [ruff across helper scripts and tools](https://github.com/python/cpython/blame/main/.pre-commit-config.yaml)\n- [FastAPI](https://github.com/fastapi/fastapi/blob/219ac634ab82b6321492ef97fb223b618ce13948/.pre-commit-config.yaml#L32-L37), [Pydantic](https://github.com/pydantic/pydantic/blob/5d4a3c8cb356fcdad925b7276b5338c24e6cf653/pyproject.toml#L220-L224), Pandas, and SciPy all use ruff. So do all the testing-cabal projects we rely on so heavily (testtools, fixtures, testscenarios, ...)\n\nSo yeah, I don\u0027t see any technical reason *not* to do something especially when it\u0027s done the way I\u0027ve done it here (i.e. a purely non-functional change, with nothing else included, which can be easily ignored for `git-blame` purposes).\n\nAs for the personal point, it\u0027s your time but it\u0027s also mine. I\u0027m not exactly a fly-by-night contributor around here, and auto-formatters have proven their value time and time again when it comes to (a) allowing me to make changes en masse to a large number of projects, especially when they\u0027re tooling assisted (think: sed, jedi, or an LLM) and (b) reducing the set of \"things\" I need to focus on when reviewing patches myself. You\u0027re concerned that I\u0027m wasting your time by forcing you to review this, but that\u0027s a one time cost to that which is largely ameliorated by the fact that you could pull *just* the `ruff.toml` file from this change, run `ruff` locally and get an identical outcome. By comparison, there is the cost that *I* and other contributors need to incur every time I want to make changes to this project or any other project here. I can\u0027t tell you how many hours (days?) of my life I\u0027ve wasted manually wrapping lines of code after e.g. using `sed` to rename a function or add a return type annotation. Auto-formatters kill all of that and turn it into a simple `tox -e pep8` / `ruff format` call. You noted this patch is in the middle of a larger chain: that\u0027s why it\u0027s there, and not at the end.\n\nSo yeah, I\u0027m standing by this change. Hopefully I\u0027ve put up a good enough argument in favour of it.","commit_id":"8409235fe91ac2d85bb7ea0aab65aee220310186"}],"specs/generate_specs_site.py":[{"author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"tag":"autogenerated:zuul:check","change_message_id":"dc067d77d0fe8db85750b5c3323394ec4c463ce2","unresolved":false,"context_lines":[{"line_number":11,"context_line":"# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied."},{"line_number":12,"context_line":"# See the License for the specific language governing permissions and"},{"line_number":13,"context_line":"# limitations under the License."},{"line_number":14,"context_line":"\"\"\"Read the specs.yaml file and generate the index.html and specs.opml files.\"\"\""},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"import argparse"},{"line_number":17,"context_line":"import os"}],"source_content_type":"text/x-python","patch_set":2,"id":"a07d7812_9cf51895","line":14,"updated":"2026-06-16 22:12:40.000000000","message":"linters: E501 line too long (80 \u003e 79 characters)","commit_id":"5b630dfb3303c1a33b1e2dc95ebf9e7857f9f231"}],"tools/check_valid_gerrit_projects.py":[{"author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"tag":"autogenerated:zuul:check","change_message_id":"dc067d77d0fe8db85750b5c3323394ec4c463ce2","unresolved":false,"context_lines":[{"line_number":336,"context_line":"                    \"fix the path.\" % name"},{"line_number":337,"context_line":"                )"},{"line_number":338,"context_line":"            acl_file \u003d os.path.join("},{"line_number":339,"context_line":"                args.acldir, acl_config[len(\u0027/home/gerrit2/acls/\u0027) :]"},{"line_number":340,"context_line":"            )"},{"line_number":341,"context_line":"            if not os.path.isfile(acl_file):"},{"line_number":342,"context_line":"                found_errors +\u003d 1"}],"source_content_type":"text/x-python","patch_set":2,"id":"b1c0fab6_9dafe969","line":339,"updated":"2026-06-16 22:12:40.000000000","message":"linters: E203 whitespace before \u0027:\u0027","commit_id":"5b630dfb3303c1a33b1e2dc95ebf9e7857f9f231"}]}