)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"641c0201ccd739448f316a7343dc9b6b04acbd8f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c4c6c2e1_3727ade4","updated":"2026-05-07 16:22:09.000000000","message":"\u003e In what way do you rely on it? Is there some other way we can handle your workflow?\n\u003e \n\u003e I ask because the removal of this option was the start of a multi-year effort to gradually stop using topics for something that Gerrit does not intend them to be used for, regardless of OpenDev\u0027s current configuration. If there\u0027s missing functionality, maybe we can fix that without abandoning the effort.\n\nThere are two aspects to the change: controlling the topic set on Gerrit reviews, and controlling the branch name used when checking out the review.\n\nOn the former, I use topics to group my work by \"initiative\". I tend to do a lot of things where I am effectively doing the same thing but across multiple repos. Topic are the only mechanism that I\u0027m aware of that allows me to easily disambiguate patches belonging to one initiative from another. For example, I have an \"initiative\" to deprecate `foo.version` modules and `foo.__version__` attributes, which I\u0027m collecting under the `deprecate-version-module` topic:\n\nhttps://review.opendev.org/q/topic:deprecate-version-module\n\nDitto, I have a much large \"initiative\" to add type hints to as many OpenStack libraries and services as possible, which is gathered under the `typing` topic:\n\nhttps://review.opendev.org/q/topic:typing\n\nThere are changes under both topics that touch the same repos (e.g. `osc-lib`) and the topic helps me group these mentally. (Note that I am aware of tags, but those are 1:N with a changeset rather than 1:1. They also do not appear to be a first-class citizen of the Web UI (which I use for my reviews)).\n\nOn the latter, I rely on branch names to indicate who authored patches and what they might be targeting. For example, if I download a patch by you that I plan to modify/build-on, the branch name will make it obvious at a glance that I am building on/modifying someone else\u0027s work. Without this, I need to parse `git log`.","commit_id":"77e9b46e6163f111084ae27a3e5c68e84047744d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"22f45e2a71a97fa27899fab888e26999f23c52ce","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c30cc08f_75b10022","updated":"2026-05-07 15:45:47.000000000","message":"I still need to test this locally","commit_id":"77e9b46e6163f111084ae27a3e5c68e84047744d"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"4831aed688d28f4a00537d0b5796568288ebb695","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"91460447_e33beb1b","in_reply_to":"216fd165_3eb1377a","updated":"2026-05-08 12:57:42.000000000","message":"Thanks for working with me on this.\n\n\u003e Regarding the first point: I don\u0027t quite understand why Gerrit hashtags are not suitable.  I think they are the intended mechanism for categorizing work like you describe.  It\u0027s true that they are 1:N but that doesn\u0027t impact the ability to identify all changes related to \"deprecate-version-module\".  I use them, along with others, for exactly that purpose.  For example, the nodepool-in-zuul effort: https://review.opendev.org/q/hashtag:niz\n\u003e \n\u003e As for their citizenship, perhaps I\u0027m missing something, but they appear to be just as visible and editable in the web UI as topics.\n\nI can\u0027t attach a screenshot here, but if I go to https://review.opendev.org/, I see the following columns: `#`, `Subject`, `Owner`, `Reviewers`, `Repo`, `Branch`, `Waiting`, `Status`, `CR`, `RP`, `V`, `W`. The `Branch` column include the topic in brackets and is clickable to allow me to filter changes by this topic. This allows for very easy disambiguation between changes. I have looked through my settings but couldn\u0027t find a way to change this dashboard to show tags by default. Perhaps this is this something that can be enabled on a deployment-wide basis though?\n\n\u003e Regarding the second point, I have no objection to git-review creating the local branch names as you suggest as long as there is no interaction with topics.\n\nI think that\u0027s difficult to do with hashtags due to their 1:N nature. Author alone is better than nothing, but topic gave me much more. For example, if I downloaded https://review.opendev.org/c/openstack/nova/+/985621 with older `git-review`, my local branch would be `review/ashigupt/eventlet-removal` which is (IMO) very informative. I imagine we don\u0027t want to/can\u0027t munge all tags, since that could result in extremely long, unhelpful branch names.","commit_id":"77e9b46e6163f111084ae27a3e5c68e84047744d"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"c14fb87c156311401cf8b037ff07d07a548d5872","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"216fd165_3eb1377a","in_reply_to":"c4c6c2e1_3727ade4","updated":"2026-05-07 18:55:48.000000000","message":"Regarding the first point: I don\u0027t quite understand why Gerrit hashtags are not suitable.  I think they are the intended mechanism for categorizing work like you describe.  It\u0027s true that they are 1:N but that doesn\u0027t impact the ability to identify all changes related to \"deprecate-version-module\".  I use them, along with others, for exactly that purpose.  For example, the nodepool-in-zuul effort: https://review.opendev.org/q/hashtag:niz\n\nAs for their citizenship, perhaps I\u0027m missing something, but they appear to be just as visible and editable in the web UI as topics.\n\nRegarding the second point, I have no objection to git-review creating the local branch names as you suggest as long as there is no interaction with topics.","commit_id":"77e9b46e6163f111084ae27a3e5c68e84047744d"}]}