18:00:15 #startmeeting tc 18:00:15 Meeting started Tue Apr 23 18:00:15 2024 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:15 The meeting name has been set to 'tc' 18:00:43 hello everyone; welcome to the weekly meeting of the OpenStack Technical Committee 18:01:19 O/ 18:01:21 JayF kindly set me up with a bunch of notes to run this meeting; but he's here in person and i'll throw in a #chair just in case 18:01:21 o/ 18:01:25 #chair JayF 18:01:25 Current chairs: JayF gouthamr 18:01:30 A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct 18:01:33 o/ 18:01:36 o/ 18:01:38 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 18:01:46 #topic Roll Call 18:02:17 \o 18:02:17 slaweq is away today 18:02:20 o/ 18:02:25 o/ 18:02:40 i haven't seen any other absences here, on the ML or on https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 18:03:09 so a reminder, that you can use these forums to tell us you can't be here during these meetings 18:03:46 o/ 18:05:39 * gouthamr does mental math.. 18:05:40 quorum checks out; lets continue 18:06:06 #topic TC vPTG 2024.2 18:06:39 thank you JayF for compiling a summary for the openstack-discuss mailing list 18:06:48 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/MHP3MMS7Z6DJK7EAXAIDWDK3DU4ZXELK/ ([tc] TC vPTG 2024.2 Summary / Notes) 18:07:23 we have identified several action items; and we can start checking on these during this meeting, and in future meetings 18:08:50 several governance changes are being proposed, and many of these are follow ups from the TC discussions at the PTG.. 18:09:14 i'll take note to revisit this until we have ack'ed all our AIs 18:09:28 does anyone want to bring up anything specific wrt $topic 18:09:52 I want to mention the unmaintained transition for zed 18:10:10 +1 18:10:18 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/WIEIJVVBD36RBHP2MP4BWW4F5SFPK4FA/ ([PTL][release][stable] Transition Zed to Unmaintained) 18:10:19 #link https://review.opendev.org/q/topic:%22zed-unmaintained%22 18:10:46 didn't we want to decide about eoling the older branches first? 18:11:59 o/ Sorry! 18:12:00 I think, we should but giving some time of around 1-2 months after the announcement in ML 18:12:10 I haven't seen any response to elodille1's mail yet and my impression is that the current unmaintained team is too small to really get the current bunch of branches and repos into a good shape 18:12:27 I think elodilles already made the ML announcement about that ? 18:12:39 gmann: so should we delay transitioning zed until after that period? 18:12:40 we just started looking on current unmaintained branches after the ptg 18:12:57 s/we/in osa we/ 18:12:58 frickler: I am ok either way delay or go in parallel 18:13:17 and capacity of unmaintained team is also really a question 18:13:18 it's still unclear to me why control of "unmaintained" branches would need to be so restricted 18:13:33 thought that was part of the point of saying they're unmaintained 18:13:43 me too 18:13:48 +1 18:14:01 the point is to eol them once they are no longer cared for 18:14:17 though, I also miss a process for teams to "subscribe" for caring for 18:14:18 +1 i would support the idea that unmaintained-core can help push patches even when project maintainers are unresponsive in case we need security fixes in 18:14:26 and thus to get rid of broken CI jobs and zuul config errors 18:14:27 NOTE: these all old unmaintained branches we kept for migration to new model otherwise they have been in EM state for long right 18:14:43 I'm assuming because it has to pull off a list from somewhere? 18:14:52 and I don't see that happening 18:15:28 there still seems to be a hesitance to just eol things when nobody responds 18:15:32 I am ok to get rid of these old EM->unmaintianed branches to EOL soon if no clear interestr 18:15:54 fungi: well, user survey is not least factor in that I guess 18:16:12 fungi++ 18:16:18 and from SLURP moving to unmaintained we anyways will keep them for 1 year at least by default unless explicitly opt-out 18:16:56 Like Yoga is still one of the biggest used versions 18:17:03 user survey says "yes, please keep giving us support for old branches, so we don't need to update", but who is doing that? 18:17:23 branches lacking maintainers are dead. it's a question of officially acknowledging that by tagging them eol or pretending someone might still happen along and want to take them over (which clearly isn't happening) 18:17:33 with 2023.1 being jsut 7% 18:17:50 We have to remember there's a supply/demand element to this. Many companies who consume OpenStack would still be using Kilo (or worse) if we didn't, at some point, force a move forward. 18:18:04 we should modify this question now to convey the unmaintained model to them 18:18:11 If we keep supplying the feeling of supported branches (even when, as fungi indicates, they are dead if unmaintained), we remove some of that pressure to upgrade from users. 18:18:11 ^ +1 18:18:14 frickler: I guess I more meant - that we need more time to spread information about changed process 18:18:23 and there is no such thing called 'community support' for older branches 18:18:33 Like 6 month ago we had rocky in EM and today we're EOLing Zed 18:18:40 We are the leaders of OpenStack; sometimes that means leading by showing the good path and EOL'ing the bad paths. 18:19:02 noonedeadpunk: clarification, no we aren't EOLing Zed 18:19:05 Regular people not really reading all TC decisions 18:19:19 gouthamr: sorry, moving to unmaintaned 18:19:20 noonedeadpunk++ 18:19:41 Like for some it's still supririse that OOO died :D 18:20:03 (not saying we should care for those, jsut pointing out communication issues) 18:20:10 whole idea of unmaintained model was interested people come forward to maintain them as long as they want. if no one is interested then no harm in EOL 18:20:41 i agree that it's unlikely the broader userbase realizes we've basically started calling "extended maintenance" something else (to acknowledge the fact that its name was a bit of a lie) 18:20:52 what I see is people saying "we want to maintain this" and then nothing happening in terms of actual work 18:21:00 there's not much point maintiaining Glance when Nova is EOLed 18:21:19 true; can we make the call to EOL victoria atm? and put out a proposal suggesting a faster EOL for other branches? 18:21:31 Well, I guess I'm just saying we've become too agressive in eoling too quickly 18:21:51 my expectation is that if nova's unmaintained/yoga branch doesn't have caretaker volunteers, it's unlikely glance will either 18:22:38 that's probably what I don't really like. As I personally still trying to establish a good process to move things I'm responsible for to unmaintained and document that and adopt basically 18:22:54 and the new policy is to eol unmaintained branches with no explicit volunteer caretaker opt-in 18:22:57 I think it would be more a fly by fix from someone using it 18:23:47 Ghanshyam proposed openstack/governance master: Add DPl model & liaison reset policy https://review.opendev.org/c/openstack/governance/+/916833 18:24:29 ok, we have two quesions here 18:24:31 spotz[m]: I think the idea of a fly-by maintenance of a project branch is not something that works out well in reality. Especially in light of what happend with Murano. 18:24:43 spotz[m]: not to mention recurring items like CI maintenance :/ 18:24:50 1. any objection to move zed to unmaintained 18:24:50 2. EOling the existing unmaintained 18:24:55 * gouthamr sets a ticker on this issue.. 18:25:06 JayF: I have some doubts who outside of old Fuel-based Mirantis deployments were really using it... 18:25:25 Though 21% of deployments being on Yoga specifically is quite evidential data 18:25:29 jayf Oh no I agree - I'm just thinking that's how a fix might get submitted in the Nova/Glance example given 18:25:52 for 1 (moving zed to unmaintained ), i think there should not be any blocker as per the timelines 18:25:55 FYI Matrix and IRC are out of sync:) 18:26:11 * gouthamr ohmergod 18:26:20 and whether we EOL older unmaintained or not can wait more if we see any response on elodilles email 18:26:56 i like gmann's proposal here.. 1) moving zed to unmaintained follows our existing process since we have yet-another-stable-branch that showed up 18:27:31 and i support disconnecting it from (2) - which is also an opportunity to give ourselves less work given we have a mess of unmaintained branches 18:27:45 Something that might help bring clarity here 18:27:59 we talk about EOL'ing older branches as a unified thing, but many projects may have already EOL'd them in some cases 18:28:19 If we were explicit about what projects still had active branches, it might act as a stronger call to actions to contributors who affiliate closely with those projects 18:29:06 actually. talking about that. it;s also a bit annoying, that not all projects follow same releasing process despite being on the same release policy 18:29:31 different problem? 18:29:41 which has been case for long time or since starting 18:29:46 like one would expect to have EOM and EOL tags for, say, Yoga when no unmaintained/yoga exist? But it's not always a case 18:30:13 ah; that seems like an omission.. 18:30:57 nah, it's just project moved to EOL before we made EOM... 18:31:03 and one thing I would like to see that TC less force/policy/discuss about unmaintained things :) and leave it to unmantained liaisons or maintainers 18:31:14 gmann++++++ extremely agree with that 18:31:28 haha; that seems like a nice way to move on to other discussion items here and take this to long form 18:32:00 frickler: we don't have a conclusion here, but, i would like to encourage a discussion on the channel or the ML once we wrap up 18:32:17 I thought we wanted to setup the model/policy and hand over to unmaintained group/liaison and not decide when and which branch goes to unmaintained/EOL 18:32:42 I would agree if there were no zuul config errors 18:32:58 but I also agree that we should move on for now 18:33:00 any other PTG concerns that can't wait? i promise a structured check-in on AIs soon; but anything else that you'd like to note? 18:33:31 going once.. thrice.. 18:33:39 #topic 2024.2 TC Tracker 18:33:42 #link https://etherpad.opendev.org/p/tc-2024.2-tracker (Technical Committee activity tracker) 18:33:53 ^ the vast emptiness of our tracking :) 18:34:07 /jk 18:34:30 please help throw items in that we'd care about for this release cycle (and a bit beyond) 18:35:03 i will take some items out of our PTG AIs as well, but feel free to correct things along the way; this will be a recurring item in our meetings 18:35:39 since you'll share your thoughts directly on the etherpad 18:35:42 #topic Ongoing business 18:35:50 ++ 18:36:04 i'd like to close out on things that JayF (and others) kicked off a formal-vote on 18:36:26 #link https://review.opendev.org/q/topic:%22formal-vote%22+status:open (Open Formal Vote items) 18:37:06 i'd like us to tackle the attention that the freezer items have been getting 18:37:11 I wouldn't mind working through https://review.opendev.org/c/openstack/governance/+/915021 so we can move forward 18:37:22 #link https://review.opendev.org/c/openstack/governance/+/915727 (Assign Dmitriy Rabotyagov as Freezer PTL) 18:37:36 #link https://review.opendev.org/c/openstack/governance/+/914911 (Transition Freezer project to DPL) 18:38:01 noonedeadpunk: would you like to share anything wrt these? 18:38:40 are you leaning towards dropping https://review.opendev.org/c/openstack/governance/+/915727 yourself? 18:38:43 well... I've discussed it for a while now 18:39:12 yes, you have the plank for 30 more seconds :) 18:39:15 And I think that DPL model might be more beneficial right now to onboard new core team 18:39:29 I prpoposed the DPL liaison monitoring things in this #link https://review.opendev.org/c/openstack/governance/+/916833/1 18:39:34 noonedeadpunk: ++ 18:39:37 #link https://review.opendev.org/c/openstack/governance/+/916833/ 18:39:50 though I see not everyone agree, so I did pushed alternative, that I don't like but for the sake of the progress ok with it as well 18:40:02 but irrespective of that I do not see why we are not giving go ahead to freezer DPL mode 18:40:04 I honestly doubt dpl have any impact on onboarding new cores, neither is ptl 18:40:08 I was just reading thorugh it 18:40:36 noonedeadpunk: ah; ty... i'm hoping JayF will pitch into gmann's proposal here: https://review.opendev.org/c/openstack/governance/+/916833/ 18:40:36 you can make ppl more important and repsonsible by giving them dedicated roles in project 18:40:39 and keep involved 18:40:41 and having DPL model or PTL model does not means we can move it from Inactive state. that need a lot other activities to check 18:41:05 Please don't not-merge a thing just because a single tc-member (me, in this case) has a -1 on it 18:41:14 (or me) 18:41:14 noonedeadpunk: you'll be first among equals whether you're PTL or leader of DPLs (lol, just introduced a new governance category) 18:41:29 and I suspect, after reading gmann's proposal, that I'll likely flip the vote on that DPL proposal once his gets momentum and some feedback 18:41:40 You can't motivate non existing ppl interested in project 18:41:44 perfect; ty for looking 18:41:58 gtema: so who told you they're non-existent? 18:42:31 Otherwise this would not end in the current situation 18:42:32 I do have communication with couple of orgs about their participation 18:43:07 not all of them just decided about migration to openstack. and having DR is quite a contributing factor to that decision 18:43:15 noonedeadpunk++ good stuff; i understood gtema's remark to be general 18:43:16 It won't happen overnight, but well 18:43:42 thanks for persisting.. 18:43:44 there's interest at least 18:44:38 noonedeadpunk: interesting. I have done PoC on freezer long back in 2018 i think. but that time it was not so ready or perfect 18:44:57 and it did not fit in our customer requirements 18:45:20 I did around same time as well.... 18:45:23 but do not know the current status and seeing interest in this is good 18:45:43 Eventually, most "interest" is around some scheduler for cinder-backups more or less as well as lifecycle 18:45:51 i suspect the rest of the open patches need some eyes.. tc-members, i'll expect us to look and timebox our reviews here.. if you think something shouldn't be merged, please let us know with a -1... 18:45:53 gmann: that two lines, is exactly the reason I care so much about project activity: I've had many conversations where experiences like that have led people to be suspicious of all openstack projects being mature at the task they claim to do 18:45:54 not client agent part 18:46:15 gmann: re: POC of a project just not fulfilling requirements 18:46:25 if you intend to abstain from a vote, please let us know again by commenting as such 18:47:04 if you don't already use it, there's a link to this useful dashboard in our TC documentation 18:47:06 JayF: yeah but we should give new people chance or more time to see if things can be improved. but I got what you are pointing to which make sense too 18:47:17 #link 18:47:17 https://review.opendev.org/dashboard/?title=Technical+Committee+Inbox&foreach=project%3Aopenstack%2Fgovernance+is%3Aopen&My+proposals=owner%3Aself&Formal+Vote+Items+I+have+not+voted+on+yet=topic%3Aformal-vote+NOT+(+label%3ARollCall-Vote%2B1%2Cself+OR+label%3ARollCall-Vote-1%2Cself+)&Has+at+Least+One+Objection=(+label%3ARollCall-Vote%3C%3D-1+OR+label%3ACode-Review%3C%3D-1+)&Quickies=(+topic%3Atypo-fix+OR+topic%3Acode-change 18:47:17 +OR+topic%3Adocumentation-change+OR+topic%3Aproject-update+)&Formal+Vote+Items=topic%3Aformal-vote&Goal+Items+I+Haven%27t+Voted+On=path%3A^goals%2F.*+NOT+(+label%3ARollCall-Vote%2B1%2Cself+OR+label%3ARollCall-Vote-1%2Cself+)&I+Haven%27t+Voted+on+this+Draft=NOT+(+label%3ARollCall-Vote%2B1%2Cself+OR+label%3ARollCall-Vote-1%2Cself+)&Everything= (Governance reviews dashboard) 18:47:20 ugh 18:47:41 that's one heck of a url 18:47:46 eww 18:47:49 I'll note many of those dashboard links (even when not mangled by IRC) require login to work 18:47:59 noonedeadpunk: ohk, I was looking more on client-agent things 18:48:32 this part is very questionable still.... 18:48:40 true 18:48:42 k 18:49:18 spotz[m]: i didn't ignore your link earlier 18:49:43 I'm so out of sync following on IRC and Matrix:) 18:50:00 Yeah, matrix today sucks 18:50:04 #link https://review.opendev.org/c/openstack/governance/+/915021 (Update to include docs and miscellaneuos repos for AC status_ 18:50:22 ^ i'll copy some folks; but please ack this review as well.. 18:50:45 I think I left comment there which is still not answered or resolved 18:50:47 ;et me check 18:50:48 let 18:50:55 i'll follow up on this channel with some more review concerns 18:51:20 You were answering a lot of the concerns gmann so if I missed one you had let me know 18:51:31 moving on.. 18:51:33 #topic 2025.1 Elections 18:51:34 gouthamr: many of them might be eligible to merge 18:51:47 gmann: ack; i'll catch up and help move these 18:52:01 sooooo, sorry to drop this topic in this early 18:52:08 * JayF wonders if gouthamr has been introduced to `tox -echeck-review-status` :D 18:52:14 spotz: I think discussion going on there. other also have some point. I need to check if anything pending on me answer/reply 18:52:35 well, 2025.1 elections will be happening in 2024 ;) 18:52:38 Yeah it's gotten a bit confusing 18:52:53 but, i realized that a while ago frickler added election deadlines to the Caracal release schedule; and i thought, why don't we do this all the time 18:52:55 JayF: I think yes. this is great help for chair and magic script 18:52:59 but, we crawl before we walk 18:53:17 gmann: did you make the magic script? If so consider this a belated thanks :D 18:53:21 i was going to put out an early call seeking election officials for the 2025.1 elections 18:53:24 the earlier the better with election scheduling 18:53:42 So we can keep reminding folks to submit 18:53:48 ++ 18:53:55 Are those election dates set yet? It's hard to know if I can volunteer without being able to compare to a calendar 18:54:12 JayF: not me. I think doug or ttx or mnaser maybe and later on it was fixed/amend it to improve. 18:54:15 or point them to it when they say they were only looking at the [$project] emails on openstack-discuss and missed [election] 18:54:21 JayF: A lot of them are hard coded in with the release schedule 18:54:45 ack, I'll check offline 18:54:47 on election, we need TC member to liaison to monitor election deadlines/etc 18:55:01 Well you have to tell the script the date to base it's dates off of but.. 18:55:07 I may be willing to be that volunteer need to check schedules as I have a busy second-half of the year 18:55:11 check-review-status was blessed to me by doug :) 18:55:12 I am, not sure if anyone volunteer fot that 18:55:16 ++ 18:55:17 spotz: even doing like "what were this election deadlines +6months) 18:55:35 mnaser: ++. that is really helpful to all chairs 18:55:56 jayf yeah it should be able to, it won't send generate emails but we can get the dates from it to publish ourselves 18:57:16 Elections last time were in the R-2 week 18:57:42 and per our charter, its the latest we can hold them 18:57:50 at least gives you an opportunity to see if it's falling across events or majoy holidays 18:57:52 deadline as per charter is election to be held between R-3 to R-8 (i will confirm again) 18:57:59 These elections are collectively held (from the nomination start date until the voting end date) no later than 2 weeks prior to each cycle final release date (on or before ‘R-2’ week) 18:58:26 ^ excerpt from https://governance.openstack.org/tc/reference/charter.html#election-for-ptl-seats 18:58:28 (between ‘R-8’ and ‘R-2’ week). gouthamr ++ 18:59:48 So extrapolating that, Sep 16-Sep 20th can be a candidate for the election week; once we have election official volunteers we can finalize this 19:00:02 we're T-1 minute to wrapping this up 19:00:13 haha 19:00:45 don't we have 2 week elections now? 19:00:55 alright we're at time; but we can continue the after-discussions in this channel and ML 19:01:04 yes, 2 week nomination and 2 week poll 19:01:10 sorry we didn't have open discussion today 19:01:11 Weel for campaigning and a week to vote 19:01:30 thank you all for attending and for the spirited discussion 19:01:33 #endmeeting