)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"3db7b3185d03bec38ce822c1495e0212a5035700","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7be68940_a149d86a","updated":"2025-06-13 15:28:00.000000000","message":"I\u0027m a bit hesitant with this. *-last tags were used formerly for branches in Extended Maintenance, later for branches in Unmaintained. Do we really want to create tags for EOL\u0027d non-SLURP branches? I mean, well, we could use them if someone plays with an environment that uses 2023.2-eol tagged components, but is that a likely scenario? Is there other situation where 2023.2-last tags are needed?\n\nGiving -1 to highlight my question. (note that i\u0027m not completely against this, i just wonder if this is needed at all)","commit_id":"1e6143a90d93d9b80a6027f0bab9371ad121fd50"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"65ebe518c12ec3751f5ebf8694b62ef10b647db4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1e3c0d1c_12797d90","updated":"2025-06-13 01:19:08.000000000","message":"This is needed by https://review.opendev.org/q/topic:%222023-2-last%22","commit_id":"1e6143a90d93d9b80a6027f0bab9371ad121fd50"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"47bdf6dca4c71f6a403eca2764b6bc286c47b5b4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a0fa19cb_6bfa9ed1","updated":"2025-06-13 10:05:49.000000000","message":"seems reasonable to me. procedural PTL-approval for code change","commit_id":"1e6143a90d93d9b80a6027f0bab9371ad121fd50"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"7d2f59d3e4b8dd24915ff1265bcc3b063297311c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"22e0aa5f_56190eb0","in_reply_to":"055ede56_9e06006b","updated":"2025-06-13 20:19:43.000000000","message":"thanks for the explanation Ghanshyam. So, basically, we are tagging 2023.2-last to have the \u0027most recent version\u0027 (that is still supported by 2023.2 Bobcat) in the table [1]. it definitely will look nicer if we\u0027ll have there a \u00272023.2-last\u0027 tag instead of some false recent version. on the other hand i still feel that it\u0027s a bit of unnecessary to mark which is the last supported tag of a tempest plugin for an **EOL** series o:) but as i said, i\u0027m not against it, i just think it\u0027s kind of unnecessary o:)\n(yes, i also understand that if an operator has 2023.2 Bobcat deployment then they might want to use 2023.2-last tagged tempest plugins for testing their existing envs, though i guess it\u0027s less likely operators choose to stay on non-SLURP series instead of a SLURP one, but i might be too idealistic again o:))\n\nanyway, the code looks good to me, so let\u0027s merge this and we can start tagging the tempest plugins with 2023.2-last tags.\n\n[1] https://releases.openstack.org/bobcat/#tempest-plugins","commit_id":"1e6143a90d93d9b80a6027f0bab9371ad121fd50"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"89f61ba39c846427aae8c1e2e87c26dc3383b6a3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"055ede56_9e06006b","in_reply_to":"7be68940_a149d86a","updated":"2025-06-13 16:16:12.000000000","message":"This is a completely new situation we hit where branches are going directly to EOL (without transitioning to EM or unmaintained). I should have explained it more in commit msg.  For any new ones referring to this comment, I am writing a little history here which many of you already know.\n\nGoal: \n-----\nIn the past (in the Queen release), one of the operators provided feedback to have a first and final/last tag from the *branchless* Tempest and its plugins for any release they start and stop supporting. To achieve that, we started:\n- Release tempest and plugins with every release (first tag to start support that release)\n- Release tempest and plugins \u003cseries\u003e-last tag when it stops supporting a particular release.\n\nTo do the latter part (-last tag), Tempest process[1] is when any branch moves to EM state (unmaintained now), then Tempest and its plugins are released \u003cseries\u003e-last tag.\n\nSituation changed here:\n-----------------------\nTill now, there was no case where release moves to EOL without transiting from EM/unmaintained state. And Tempest/plugins have already released their \u003cseries\u003e-last tag when those release moved to EM/unmaintained. So no new tag was needed when release move to EOL.\n\nNow, non-SLURP releases can move directly from supported to EOL (with no EM/unmaintained branches). In this case Tempest did nt get chance to release  \u003cseries\u003e-last to mark end of support for these non-SLURP. That is reason we have to release it for non-SLURP when they move to EOL. \nNOTE: this is the first release in this new case.\n\n\n[1] https://docs.openstack.org/tempest/latest/tempest_and_plugins_compatible_version_policy.html","commit_id":"1e6143a90d93d9b80a6027f0bab9371ad121fd50"}],"openstack_releases/series_status.py":[{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"7d2f59d3e4b8dd24915ff1265bcc3b063297311c","unresolved":false,"context_lines":[{"line_number":53,"context_line":""},{"line_number":54,"context_line":"    @property"},{"line_number":55,"context_line":"    def is_eol(self):"},{"line_number":56,"context_line":"        return self.status \u003d\u003d \u0027end of life\u0027"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"    @property"},{"line_number":59,"context_line":"    def is_em(self):"}],"source_content_type":"text/x-python","patch_set":1,"id":"9105c07b_27b5bde1","line":56,"updated":"2025-06-13 20:19:43.000000000","message":"hmm, i\u0027m quite surprised that we haven\u0027t had this yet here :-o (we have is_eol() in openstack_releases/deliverable.py)","commit_id":"1e6143a90d93d9b80a6027f0bab9371ad121fd50"}]}