| opendevreview | Rodolfo Alonso proposed openstack/releases master: New os-ken release 2.11.1 https://review.opendev.org/c/openstack/releases/+/935265 | 07:47 |
|---|---|---|
| frickler | JayF: I can do the eol tags for you, no need to go through the project-config hassle unless you really want to. I'd also argue that we likely still want to merge that patch anyway, if only for documentation purposes, since we do have the same in place for ocata | 09:00 |
| frickler | release-team: please review https://review.opendev.org/c/openstack/releases/+/935064 so that we can proceed with the eom->eol transitions. I'll then update 935041 according to the feedback and make it a stack starting at the latest branch | 09:08 |
| opendevreview | Bartosz Bezak proposed openstack/releases master: kayobe: 2024.2 rc1 https://review.opendev.org/c/openstack/releases/+/935271 | 09:55 |
| frickler | elodilles: fyi this would be my next dataset to base eols on, note that is does include nova, so you may want to actually looks into this https://zuul.opendev.org/t/openstack/config-errors?branch=unmaintained%2Fvictoria&severity=error&skip=0 | 10:09 |
| elodilles | frickler: ACK, noted. i tend to check the zuul config errors and fixed a lot already, but i always try to start from the most recent branch, hence i did not get to victoria in many cases (sometimes stable branches are also affected and even master). the problem is that time to time new things were deleted, but i'm on it, beside my other duties | 10:30 |
| frickler | elodilles: well it was you who requested that I start at victoria ;) | 10:40 |
| elodilles | indeed :) | 10:44 |
| elodilles | as that is the process o:) (no release should be skipped) | 10:44 |
| frickler | the process also says all branches with broken CI shall be closed, but you seem to object to that part of the process | 10:46 |
| elodilles | i don't recall, is there a grace period or should we delete them instantly? | 10:50 |
| frickler | the policy doesn't mention any grace period. I would consider the time since the branch transition to eom until the next eom event to be sufficient for that | 10:50 |
| elodilles | i still think that it could be useful for some people to keep old branches open, even if we see only minimal activities (and less and less on the oldest branches). i volunteered to do some maintenance on these old branches, and although i get help time to time, there's always new things to fix. if the community insists on deleting these old branches then i have to accept that | 10:57 |
| elodilles | and note, that i didn't want to delete instantly any CI jobs that are failing, rather try to find why it is failing. it's relatively easy to disable any failing CI job to make the gate pass. but that is not my intention at all. | 10:59 |
| frickler | to me, the question really is what is the benefit that you get out of keeping these branches open that couldn't also be fulfilled by say a company owned fork on codeberg or even github if needed. is it really worth the added efforts on the sides of the release team, the opendev team and others? especially if you only really care for a single branch? | 12:17 |
| elodilles | frickler: CI + the possibility for everyone to do some maintenance upstream, where other can consume bug fixes. it's not only for victoria, but for other branches as well. maybe some vendor / company / developer see some value in it and put some effort in it, if not now, then later. if we don't even give the possibility, then it could never happen. i know, maybe this approach is too idealistic | 13:17 |
| elodilles | noonedeadpunk: hi, sorry for the late ping: we have a task for this week to propose branch cuts for trailing projects where there are no stable/2024.2 yet. should i push the patches for that or do you plan to do that? | 13:34 |
| elodilles | noonedeadpunk: i'm talking about OSA + OSA-roles o:) | 13:35 |
| noonedeadpunk | elodilles: I'll do that, but we're still finilizing some things | 13:45 |
| noonedeadpunk | so probably it won't be this week | 13:45 |
| opendevreview | Merged openstack/releases master: Release python-zaqarclient for Epoxy-1 milestone https://review.opendev.org/c/openstack/releases/+/934631 | 13:47 |
| opendevreview | Merged openstack/releases master: kayobe: 2024.2 rc1 https://review.opendev.org/c/openstack/releases/+/935271 | 13:47 |
| elodilles | noonedeadpunk: sure, no problem, thanks in advance o/ | 13:48 |
| frickler | elodilles: yes, I see the idea, but I don't think we can keep everything open forever, just in case someone comes along years later. I think waiting for one cycle after the eom tag was made must be enough | 13:49 |
| frickler | elodilles: what I won't object to is keeping branches open that actually have had non-bot-generated patches proposed or merged https://review.opendev.org/q/branch:unmaintained/victoria+-owner:infra-root@openstack.org | 13:49 |
| frickler | that's 65 patches spread over 30 repos | 13:51 |
| elodilles | frickler: yeah, i don't expect and want to keep it open forever, but one cycle after EOM is too short in my opinion. when on summits on forums the question was on the agenda 'what versions do you have on production' there were insanely old versions mentioned every time. | 13:52 |
| elodilles | of course the best is if everyone upgrades all the time to the latest release. but that's not happening all the time in reality | 13:54 |
| frickler | I have two questions regarding this (not necessarily to you, but more in general): a) how many of these old deployments would even be in a position to and willing to deploy bugfixes? so would they really profit from the unmaintained branches? | 13:58 |
| frickler | and second: won't that number only increase even more, if we decrease the pressure to do timely upgrades? | 13:58 |
| elodilles | good point :) | 14:00 |
| elodilles | but let's have a meeting | 14:00 |
| elodilles | #startmeeting releaseteam | 14:00 |
| opendevmeet | Meeting started Fri Nov 15 14:00:56 2024 UTC and is due to finish in 60 minutes. The chair is elodilles. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'releaseteam' | 14:00 |
| ttx | o/ | 14:01 |
| frickler | \o | 14:01 |
| elodilles | Ping list: release-team | 14:01 |
| elodilles | #link https://etherpad.opendev.org/p/epoxy-relmgt-tracking | 14:01 |
| elodilles | (my copy paste buffer is dying...) | 14:01 |
| elodilles | o/ | 14:02 |
| elodilles | we are at line 84 | 14:02 |
| elodilles | let's start! | 14:03 |
| elodilles | #topic Review task completion | 14:03 |
| elodilles | 1st task was: | 14:03 |
| elodilles | 'Ensure that all trailing projects have been branched for the previous series. (elod)' | 14:03 |
| elodilles | i saw 3 repos from 2 teams that needed stable/2024.2 branching: | 14:04 |
| elodilles | kayobe: https://review.opendev.org/c/openstack/releases/+/935271 just merged | 14:04 |
| elodilles | so this is done ^^^ \o/ | 14:04 |
| elodilles | and | 14:05 |
| elodilles | OSA + OSA-roles | 14:05 |
| frickler | seems noonedeadpunk is onto that | 14:05 |
| elodilles | i've pinged noonedeadpunk and he promised to prepare the patches | 14:05 |
| elodilles | in the coming weeks | 14:05 |
| elodilles | we still have 3 weeks until Dalmatian cycle-trailing release deadline: https://releases.openstack.org/epoxy/schedule.html#e-cycle-trail | 14:06 |
| noonedeadpunk | I'm aware of deadlines and will push patches once we will be ready for them | 14:07 |
| noonedeadpunk | we had very quiet cycle and were hoping to get release early | 14:07 |
| noonedeadpunk | but plenty of ideas raised right after ptg | 14:07 |
| elodilles | noonedeadpunk: thanks for the heads up, sounds like a plan! | 14:08 |
| elodilles | that's also good to hear :) | 14:08 |
| noonedeadpunk | (and CI failing on us heavily recently) | 14:08 |
| elodilles | :-o | 14:08 |
| elodilles | hmm, that's not good to hear :/ | 14:08 |
| elodilles | anyway... fingers crossed, and thanks again for the info. | 14:09 |
| elodilles | 2nd task was: | 14:09 |
| elodilles | 'Propose autoreleases for cycle-with-intermediary libraries which did not release since the previous release. (elod)' | 14:09 |
| elodilles | https://review.opendev.org/q/topic:epoxy-milestone-1 | 14:10 |
| elodilles | as you can see, about third of them have merged, | 14:10 |
| ttx | should we force or just ignore the other ones? | 14:10 |
| elodilles | since we are at milestone-1 i guess we can ignore | 14:11 |
| elodilles | but i'll ping damani to review the patches maybe | 14:11 |
| elodilles | as most of the remaining patches are oslo deliverables | 14:11 |
| elodilles | if that is OK for you | 14:12 |
| ttx | ok... maybe we can abandon them next week | 14:12 |
| ttx | give a last chance to everyone | 14:12 |
| ttx | and yes oslo ping sounds like a good idea | 14:12 |
| elodilles | ttx: ACK, i'll do the pinging and abandon the ones that do not get responses in some days | 14:13 |
| elodilles | we have a task for that anyways o:) | 14:13 |
| opendevreview | Merged openstack/releases master: New os-ken release 2.11.1 https://review.opendev.org/c/openstack/releases/+/935265 | 14:13 |
| elodilles | i mean, to keep track of the 'milestone-1 exceptions' | 14:13 |
| elodilles | 3rd task then: | 14:14 |
| elodilles | 'To catch if there are acl issues in newly created repositories, run tools/aclissues.py (ttx)' | 14:14 |
| ttx | done that -- no issue reported | 14:14 |
| elodilles | cool \o/ | 14:14 |
| elodilles | and that was all the tasks | 14:15 |
| elodilles | #topic Assign R-19 and R-16 week tasks | 14:15 |
| elodilles | though as i see we have not much to assign, | 14:15 |
| elodilles | i've added 'all' to 'milestone-1 exceptions' | 14:16 |
| ttx | Took the chairing | 14:16 |
| elodilles | ttx: +1, thanks! | 14:16 |
| elodilles | #topic Review weekly countdown email | 14:16 |
| elodilles | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:17 |
| elodilles | please review ^^^ | 14:17 |
| frickler | lgtm | 14:18 |
| ttx | lgtm, added final release date | 14:18 |
| elodilles | good, thanks! | 14:18 |
| elodilles | will send if later today | 14:18 |
| elodilles | s/if/it | 14:18 |
| elodilles | #topic Open Discussion | 14:19 |
| elodilles | (frickler) Fix for eom->eol transition | 14:19 |
| elodilles | https://review.opendev.org/c/openstack/releases/+/935064 | 14:19 |
| frickler | as discussed yesterday, the validation currently fails since the e.g. stable/zed branch is gone | 14:20 |
| frickler | if someone feels inclined to amend the code to actually check the unmaintained/* branch, that would be nice, too | 14:20 |
| frickler | but the above would just skip the check for -eol tags | 14:21 |
| frickler | (the check whether tag-eol is actually on a proper branch) | 14:21 |
| ttx | yes I think that works | 14:22 |
| elodilles | sounds + looks good to me with a quick glance, i'll review it thorougly after the meeting | 14:22 |
| elodilles | anything else to add here? | 14:23 |
| ttx | (nothing from me) | 14:25 |
| elodilles | OK then let's move on | 14:25 |
| elodilles | '(frickler) Directly EOL EOM branches for retired projects?' | 14:25 |
| elodilles | (solum) https://review.opendev.org/c/openstack/releases/+/934475 | 14:26 |
| elodilles | (ec2-api) https://review.opendev.org/c/openstack/releases/+/934469 | 14:26 |
| elodilles | (kuryr) https://review.opendev.org/c/openstack/releases/+/934477 | 14:26 |
| elodilles | (winstackers) https://review.opendev.org/c/openstack/releases/+/934483 | 14:26 |
| elodilles | (senlin) https://review.opendev.org/c/openstack/releases/+/934508 | 14:26 |
| elodilles | (sahara) https://review.opendev.org/c/openstack/releases/+/934496 | 14:26 |
| elodilles | (murano) https://review.opendev.org/c/openstack/releases/+/934504 | 14:26 |
| frickler | I must admit I didn't check yet how we handled these last cycle, but I think I remember we did some direct eols there, too? | 14:26 |
| elodilles | i don't have strong feelings here | 14:26 |
| elodilles | in general, i'm OK to EOL them | 14:27 |
| ttx | I think it makes sense. If ether is no team to continue maintaining them, it's even more true for old branches | 14:27 |
| elodilles | but have to check whether older branches are still open (unmaintained/*) | 14:27 |
| ttx | Maybe just a quick email thread to explain and give anyone opportunity to object | 14:27 |
| fungi | technically, unmaintained branches are supposed to be eol'd if nobody volunteers to be their caretaker | 14:28 |
| fungi | i had previously assumed, based on the original discussions at the forum and subsequently in drafting of the tc resolutions, that most of those branches would go eol after one cycle of being unmaintained | 14:29 |
| fungi | since usually nobody volunteers to keep them in working condition | 14:29 |
| frickler | fungi: well the problem with the latter is that nothing is happening by default | 14:29 |
| frickler | so we still need to actually implement that part of the policy | 14:29 |
| fungi | the plan was that they be eol'd by default | 14:29 |
| frickler | for some value of "we" | 14:30 |
| elodilles | ACK, then I will drop a mail to ML and state that we are about to EOL solum, [..], murano in a week if noone steps up. | 14:30 |
| fungi | but yeah, maybe that part of the process was never clearly defined, so it's not actionable as-is | 14:30 |
| frickler | well it is clearly defined in the policy. it is just that the implementation differs | 14:31 |
| elodilles | #action elod to drop a mail to ML and state that we are about to EOL solum, [..], murano in a week if noone steps up | 14:31 |
| elodilles | is that OK for you? ^^^ | 14:31 |
| fungi | regardless, yes, if the project is retired then newer branches aren't being maintained which means the unmaintained branches can't reasonably continue as-is either | 14:31 |
| ttx | worksforme | 14:31 |
| frickler | elodilles: I'm not convinced that it is worth the effort, but I won't stop you, either | 14:31 |
| frickler | if someone did step up, they'd also have to revive the main branch, wouldn't they? | 14:33 |
| elodilles | yeah, since i haven't seen any activity on them (not a surprise, they are retired) so i don't expect either any response, but we will see | 14:33 |
| elodilles | frickler: that's a good question. probably yes | 14:33 |
| elodilles | some bug fix backport + CI fixes could have been done without master revival... but that's it | 14:34 |
| elodilles | alrighty then, this was the last topic | 14:35 |
| frickler | anyway, maybe some miracle happens and someone shows up, we can discuss further steps then | 14:35 |
| elodilles | :) | 14:35 |
| elodilles | indeed | 14:35 |
| elodilles | anything else to bring up before we close the meeting? | 14:35 |
| elodilles | #info next meeting is at 13th December | 14:36 |
| elodilles | just to note that we will skip some meetings in the coming weeks ^^^ | 14:37 |
| ttx | enjoy the break! | 14:37 |
| elodilles | yepp-yepp :) | 14:37 |
| elodilles | okay, if nothing else, then thanks everyone for joining o/ | 14:38 |
| elodilles | #endmeeting | 14:38 |
| opendevmeet | Meeting ended Fri Nov 15 14:38:16 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:38 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2024/releaseteam.2024-11-15-14.00.html | 14:38 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2024/releaseteam.2024-11-15-14.00.txt | 14:38 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2024/releaseteam.2024-11-15-14.00.log.html | 14:38 |
| frickler | \o | 14:38 |
| elodilles | Damani_: hi, since you are here, could you please review these oslo releases? https://review.opendev.org/q/topic:epoxy-milestone-1+is:open+reviewer:self | 14:42 |
| elodilles | mail sent to ML about the retired projects: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/J34NQ7WQWM2RZ5Y6XD6I4WB6MHENLN7V/ | 16:27 |
| elodilles | i'll wait a week and prepare the patches depending on the replies (or lack of them) | 16:28 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Transition zed-eom branches to EOL https://review.opendev.org/c/openstack/releases/+/935041 | 16:38 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Transition victoria-eom branches to EOL https://review.opendev.org/c/openstack/releases/+/935373 | 16:38 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Transition wallaby-eom branches to EOL https://review.opendev.org/c/openstack/releases/+/935374 | 16:38 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Transition xena-eom branches to EOL https://review.opendev.org/c/openstack/releases/+/935375 | 16:38 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Transition yoga-eom branches to EOL https://review.opendev.org/c/openstack/releases/+/935376 | 16:38 |
| opendevreview | Merged openstack/releases master: [cinder] Transition 2023.1 Antelope to Unmaintained https://review.opendev.org/c/openstack/releases/+/934489 | 16:58 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Transition zed-eom branches to EOL https://review.opendev.org/c/openstack/releases/+/935041 | 17:46 |
| elodilles | just a heads up that i'll run the eom branch clean up script (and keep requirements + devstack branches) in a minute | 17:57 |
| elodilles | Clark[m]: fungi: sorry, i see that some operation is ongoing on #opendev is this a wrong timing to do some stable/2023.1 branch clean-up, because i was about to run the script ^^^ | 18:00 |
| sean-k-mooney | frickler: probaly best to chat here, i dont know if you saw may watcher unmainteind branch email to the list or my commnet on https://review.opendev.org/c/openstack/releases/+/935041 | 18:00 |
| sean-k-mooney | i see htat the older branhc transtion patches have been created | 18:00 |
| fungi | elodilles: should be fine, what's going on currently is unrelated to gerrit | 18:01 |
| sean-k-mooney | i was going to ask if it made sense to create a seperate patch for watcher and related patches | 18:01 |
| clarkb | elodilles: the operation is pruning the intermediate container registry used by ci jobs. Agreed it shouldn't affect branch cleanups in gerrit | 18:01 |
| fungi | just doing some cleanup of data in swift | 18:01 |
| sean-k-mooney | related repos to do them all in one commit or not | 18:01 |
| clarkb | the last time we tried to prune this is made some jobs sad beacuse there were bugs. We think they have been fixed and don't expect problems this time but either way gerrit itself should be unaffected | 18:01 |
| elodilles | fungi: clarkb: ACK, thanks, then i'll run the script | 18:02 |
| sean-k-mooney | frickler: the current transtion patch move watcher branche to eol but does not do the same for watcher-dashboard and python-watcherclient which i think should all be move to eol togehter | 18:04 |
| elodilles | sean-k-mooney: thanks for your mail and review on the patch, i guess frickler doesn't insist on a separate patch, though i also wanted to / plan to create separate patch for the retired projects as i don't want everything to be EOL'd in the above patches... (even if that means i have to fix / reduce CI jobs for some of the projects) | 18:06 |
| elodilles | sean-k-mooney: and yepp, if watcher is about to be EOL'd then watcher-dashboard and python-watcherclient EOL'ing makes sense at the same time | 18:07 |
| sean-k-mooney | well im asking more so we are not workign across purposes | 18:07 |
| sean-k-mooney | i.e. i dont want to submit a configlcit patch for watcher* if we prefer to go with the combinded ones | 18:08 |
| sean-k-mooney | but i was going to do that before i saw frickler's patch | 18:09 |
| elodilles | frickler did it to spare some release review effort, though i'm happier with some smaller patches (though not a separate patch for every repo) than a huuuuge almost infinite patch :S | 18:10 |
| sean-k-mooney | my plan was to wait a week or so for any respone on the mailing list and create a patch late next week to eol them if no one objected. bu ti would like to cordinate that with the wider release team then just go my own way so whatever works for folks in general | 18:10 |
| elodilles | i like your plan and thanks for doing it o:) | 18:11 |
| sean-k-mooney | the other thing i need to do carfully is cordiante acess to the stable (and master) brach core teams | 18:12 |
| elodilles | but yes, let's wait for frickler's response | 18:12 |
| sean-k-mooney | baisally when we are doign this i woudl expect we may need to tweak grenade or simialr? | 18:12 |
| sean-k-mooney | i.e. to not break the 2023.1 unmaineded barnches | 18:13 |
| elodilles | is watcher used in any project's grenade job? | 18:13 |
| sean-k-mooney | other then its own i dont think so | 18:14 |
| sean-k-mooney | and of late it hasd not had really any mantaince on stable let alone unmainteed/* | 18:14 |
| elodilles | then i guess it shouldn't be a problem | 18:14 |
| sean-k-mooney | so i dont expect it to break other proejcts | 18:14 |
| sean-k-mooney | but i just dont want to creat a buch fo zuul error ectra | 18:15 |
| elodilles | then i think it won't cause any issue | 18:15 |
| sean-k-mooney | so if we need to pin to a tag or soemthing i just want to make sure people have access to do that | 18:15 |
| elodilles | and unfortunately time to time we have new zuul config errors when things are deleted (devstack-gate, nodesets, py38, etc-etc), so that's kind of normal operation :D | 18:16 |
| sean-k-mooney | oh interesting. the github mirror sync does not delete the stabel branch when it moves to unmaintained | 18:17 |
| elodilles | sean-k-mooney: ping me anytime as i'm in stable-maint group + openstack-unmaintained-core as well, so most things i could cover | 18:17 |
| sean-k-mooney | that does seam to work fine on opendev.org | 18:17 |
| elodilles | sean-k-mooney: if i remember well, we delete the branch in gerrit, and it get synced later on | 18:18 |
| sean-k-mooney | elodilles: there is one patch that woudl be nice tomerge on stable if you have time https://review.opendev.org/c/openstack/watcher/+/934996 | 18:19 |
| elodilles | and note that i'm running the cleanup script (deleting stable/2023.1 branches) right now, so there are still some left-over stable/2023.1 branches | 18:19 |
| sean-k-mooney | ah | 18:19 |
| opendevreview | Stephen Finucane proposed openstack/releases master: oslo.context 5.7.0 https://review.opendev.org/c/openstack/releases/+/935393 | 18:20 |
| sean-k-mooney | if its not synced/fixed in a week or so ill let you know but ill assume it will resolve itself | 18:20 |
| elodilles | sean-k-mooney: will look into the patch shortly | 18:20 |
| sean-k-mooney | no rush, it was just pointed out that the stable/2023.2 branch was failing so i cherry picked the 2024.1 patch that fixed it but was not backported | 18:22 |
| elodilles | and the result of the cleanup for now: https://paste.opendev.org/show/bixe2g2g9S6pQ83WBIvx/ | 18:39 |
| frickler | sean-k-mooney: if you want to eol watcher separately, please comment in the patch or amend it yourself. as I wrote in a comment there already, this thing is mostly autogenerated as a first easy step for cleanup, more stuff will follow when checking project+CI status individually | 18:39 |
| frickler | elodilles: nice | 18:40 |
| sean-k-mooney | frickler: well im more lookign for guidance | 18:40 |
| sean-k-mooney | frickler: as i said i am going ot wait a week for respocnes on the maining list | 18:41 |
| sean-k-mooney | so i can either update the patch, create my own or create one just for watcher-dashbaord adn watcher client | 18:41 |
| sean-k-mooney | i just dont want to create more work for you | 18:41 |
| frickler | then the third option would sound easiest I'd say. I personally would think having waited half a year for progress is long enough, but a week more or not doesn't really matter then, too | 18:43 |
| sean-k-mooney | sure ill go for option 3 then and just put it at the end of your existing patches | 18:44 |
| elodilles | sean-k-mooney: the watcher backport looks good to me, though watcher is one of the projects where somehow stable-maint is not in the <project>-stable-maint group so i cannot +2 it :/ | 18:51 |
| elodilles | release-team: cinderlib release-job failure (publish-openstack-releasenotes-python3 job) can be ignored i think, as cinderlib is retired and i guess the emptied repo causing the issue | 18:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!