Friday, 2026-07-03

jgilaberdviroel, I've opened https://review.opendev.org/c/openstack/releases/+/995942 to release the stable branches PTAL when you have some time12:40
dviroelack , thanks jgilaber 12:40
jgilaberI've treated all three as bug fix releases12:40
jgilaberaltough I had doubts with flamingo, considering we fixed a considerable amount of bugs12:40
dviroeldon't they need to be in 3 different patches? or it is acceptable this way?12:42
dviroelI think that is fine, there are other changes like that12:47
jgilaberI saw some doing at all once, but not sure12:55
sean-k-mooneythey can be a singel patch13:21
sean-k-mooneymost pepoel do ti as asperte but i tend to do it as one if im doign multiple branches13:22
sean-k-mooneythe first time i did that the release team were surpsied it works because its not actuly docuemtned but ya its a thing13:22
sean-k-mooneyjgilaber: with that said if there are no changes you shoudl not be doing a milesoen 2 release13:23
dviroelyeah, so epoxy has the same hash13:24
dviroelno fixes, no need for a new release13:25
sean-k-mooneyyep13:25
sean-k-mooneythat proably means we still need to focus on merging some of the expy backports13:26
sean-k-mooneyi just have not had time to look at that13:26
dviroelhttps://github.com/openstack/watcher/commits/stable/2025.1/13:27
dviroelI think that is the hash that needs update13:27
dviroelhttps://github.com/openstack/watcher/commit/d6750e40f8434f75493eda13e69bbc47b315e6d613:27
sean-k-mooneyah yep13:27
sean-k-mooneyjgilaber: there is a script to gerneate this by the way13:27
dviroelright13:28
dviroelnew-release?13:28
sean-k-mooneyyep via tox13:28
dviroelhttps://releases.openstack.org/reference/using.html#using-new-release-command13:28
sean-k-mooneytox -e venv -- new-release ...13:28
sean-k-mooneythat will automtaclly check the sha for you and grab the latest13:28
sean-k-mooneythen you ment to do a quick sumary of the change sinc e the previous sha when creating the commit message13:29
* dviroel hates how gerrit ui is slow sometimes13:29
sean-k-mooneyi think there are some load issues its not just you13:30
jgilaberhmm didn't know that, let me try14:16
jgilaberon the epoxy branch, the hash is indeed wrong, looks like I made a mistake when copying the hash from github14:20
jgilaberbut there is a new commit14:20
sean-k-mooneylike this https://review.opendev.org/c/openstack/releases/+/987926 or https://review.opendev.org/c/openstack/releases/+/95846814:21
jgilaberI've asked claude to write a new commit message with more info and will update the patch commit message and with the right hash for epoxy14:25
opendevreviewsean mooney proposed openstack/watcher master: Avoid logging messaging transport URLs  https://review.opendev.org/c/openstack/watcher/+/99596014:36
sean-k-mooneyjgilaber: dviroel ^ can you give that priorty when you have time, we will need to wait for ci in anycase14:37
jgilabersure, will what happens earlier ci reporting or gerrit UI loading the patch :)14:38
sean-k-mooneywe may also want to include that in the satable branch relese14:38
sean-k-mooney:) i dont know that could be a close one14:38
sean-k-mooneyit could go either way14:39
opendevreviewsean mooney proposed openstack/watcher master: Avoid logging messaging transport URLs  https://review.opendev.org/c/openstack/watcher/+/99596014:46
sean-k-mooneyforgot to add Closes-Bug14:46
dviroelack14:48
jgilaberI added my +2 the patch looks correct14:48
dviroelack, maas is deprecated and I will propose the removal this release14:50
dviroelbut it important to backport14:50
jgilaberagreed, I'll probably be out by the time CI finishes, but I think it would make sense if we merged the backports with only your approval dviroel 14:52
jgilaberplus sean-k-mooney implicit +2 as the owner of the patch14:52
jgilaberI'll -W the release patch for now to get this in once it's merged14:52
sean-k-mooneyack i think we can backprot it on monday and to the releases then on tusday14:54
sean-k-mooneywe could also jsut proceed with the release. its good to backport but not cirtical to hold the release for14:55
sean-k-mooneyi suspsect however that most of the release team (at least the US contingent) are takeing an extneded weekend14:55
dviroelright14:56
dviroelI will be here for a while, i will W+1 later14:56
dviroelif gerrit permits15:09
dviroelbtw, i proposed https://review.opendev.org/c/openstack/project-config/+/995886 yesterday, to add Review Priority label15:20
dviroelwe may just need to define what we want to express in the label as +1 and +215:21
sean-k-mooneydviroel: ya i think those values look reasonabel15:21
dviroeli copied what most of the projects defined 15:21
dviroelnova is different right15:21
sean-k-mooneyim not sure the submitable part are correct15:22
dviroelhumm15:22
sean-k-mooneythat looks like your trying to allow use to force submit things if we set prioryt ture15:23
sean-k-mooneyi ned to look that up but i dont recall havign to set that up15:23
sean-k-mooneyoh it is the same15:24
dviroelnova is different yes15:24
dviroelno?15:24
sean-k-mooneyno nova is the saem https://github.com/openstack/project-config/blob/master/gerrit/acls/openstack/nova.config#L38-L4115:24
dviroelcinder is different15:24
dviroelhttps://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/cinder.config15:24
sean-k-mooneyok those were added later15:24
sean-k-mooneyhttps://github.com/openstack/project-config/commit/dda3b6098ead3028379afb1ab1b0de9155726b7015:25
sean-k-mooneyok so what that is doing 15:26
sean-k-mooneyis saying that Review-Priority is never applabel to determingn if we can submit (merge) the patch15:27
sean-k-mooneyand regradess fo the value sumbition is valid15:27
sean-k-mooneydviroel: so ya your change is correct15:27
sean-k-mooneyit just wasnt requried wehn i made my change15:27
sean-k-mooneyone ocmment on the +2 nameing but looks ok to me overall15:30
dviroelack, it is not trivial to understand, but yeah look correct15:31
dviroelack sean-k-mooney - that's the feedback that I was waiting15:31
dviroellets see what others think15:31
*** dviroel is now known as dviroel_lunch15:32
sean-k-mooneydviroel_lunch: i woudl prefer to avoid predefinign the time we use +2 in the lable iteslf so we can evovle that as desired without changign the acls15:33
dviroel_lunchyeah, i see more as an example when to use it, but other may understand that they should be only used in the context provided. So yeah, we can be more generic in the meaning16:43
*** dviroel_lunch is now known as dviroel16:52

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!