16:00:19 #startmeeting tc 16:00:19 Meeting started Wed Mar 15 16:00:19 2023 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:19 The meeting name has been set to 'tc' 16:00:28 #topic Roll call 16:00:31 o/ 16:00:41 o/ 16:00:42 o/ 16:00:44 o/ 16:00:46 o/ 16:01:14 o/ 16:01:16 o/ 16:01:39 o/ 16:01:47 I think that is quorum :) 16:01:52 #topic Follow up on past action items 16:02:05 by my checking of https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-08-15.59.txt there appears to be no hanging action items from last week 16:02:15 JayF: knikolla[m] did we send the agenda on ML for this meeting? I did not see 16:02:59 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting 16:03:06 #link https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032715.html mentioned that it was on the wiki 16:03:33 I'm working off the agenda rosmaita in the wiki 16:03:44 **I'm working off the agenda from the wiki linked by rosmaita 16:03:58 :) 16:04:10 we need to send on ML also once we finalized agenda like 12 hr before or so. I usually used to send on Tuesday evening I think 21 UTC 16:04:32 so that community know the final agenda but anyways we can proceed for this meeting 16:04:34 Just so I'm clear; is that policy or convention? 16:05:00 it is written on meeting wiki page #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 16:05:19 it help to know the final agenda and community members can plan to attend accordingly 16:05:20 pretty useful convention I think... 16:05:33 yeah, no policy as written 16:05:35 Yeah, I agree, mainly wanting to be sure that it's OK we talk about things on the agenda if it wasn't announced properly 16:05:39 seems like it's not ideal but OK 16:05:47 yeah it is ok. 16:05:48 #topic Deciding on meeting time 16:05:56 just checking in case I missed it on ML 16:05:57 it's not limiting, it's just advisory, IMHO 16:05:57 It looks like we only have 4 responses to https://doodle.com/meeting/participate/id/er2LQQ2e/vote 16:06:10 That means 5 of us, including me, need to respond to the doodle 16:06:40 given this new time would be effective at the start of April; I propose we encourage folks to respond and do not take action on this until next meeting (3/22) 16:06:44 I think dansmith reopened on that ? 16:06:58 what? 16:07:23 Dan is one of the 4 respondants for the doodle :) so are you gmann, jamespage, and rosmaita 16:07:31 Hm, I think I have missed that somehow 16:07:37 that is like the biggest doodle i have ever seen 16:07:41 I think knikolla[m] also 16:07:42 75 options! 16:07:49 rosmaita: yeah, way too big to be useful, IMHO 16:07:51 Is everyone OK with us pushing this another week to give more time for people to respond? 16:07:59 ++ 16:08:11 should be fine as it is going to be effective from april 16:08:14 I tried to go through every hour in a given week, but.. especially with the time change implied, it was a lot of work 16:08:14 yep 16:08:19 #action Remaining 5 TC members to respond to https://doodle.com/meeting/participate/id/er2LQQ2e/vote 16:08:22 dansmith: my problem is with the interface only displaying 5 opts at a time 16:08:27 rosmaita: that also 16:08:44 I agree it's a bit tedious which is why I didn't just fill it out during the meeting just now when I realized I missed it 16:08:50 I kinda wish we could have started with a "does this time work for everyone, what about +1 hour, +1 day, etc 16:09:01 oh, knikolla[m] has to select all options as author. that is what doodle vote are now a days? 16:09:06 but just eyeballing it, even with only 4 responses, it is going to be really hard to find a time 16:09:27 it's also hard to survey the available options now because it only shows me three responses at a time for some reason 16:09:32 So how about this, can the folks who haven't responded yet try to make a point to get to it this calendar week, preferably today? 16:09:46 Then we can revisit on the mailing list before next meeting if there's no time appearing, or we don't get participation 16:10:32 I think everyone is here today (even spotz[m]) so could we short-circuit and ask if this time now works for people? 16:10:43 +1 16:10:46 That's not true though, knikolla[m] is not here 16:10:49 JayF I will do this doodle tomorrow morning my time 16:11:02 i ran into similar challenges trying to determine a new time for the security sig meetings. basically eneded up making three polls, one for cadence, one for preferred weekday, and then finally one for available times on that day of the week for the chosen cadence 16:11:06 JayF: I think that's a one-off conflict isn't it? normally knikolla[m] is here 16:11:17 Yeah, time that works for me already does not work for 2 already responded folks at very least 16:11:23 dansmith: Oh, I reread your comment; I understand now. 16:12:03 it is hard to find time work for everyone, we as elected and self nominated TC need to take it on priority. that is my opinion 16:12:20 and choose the time work for majority. 16:12:29 but anyways let's wait for all members to vote 16:12:46 I'm afraid that'll start a feedback loop where we'll isolate the effective TC membership to a single timezone or region. 16:12:56 It's a hard problem, I agree we should wait until all TC members vote on the doodle 16:12:58 and go from there 16:13:16 unless there's a second, or support for dansmith's proposal to vote on this time right now, we should probably move on 16:13:23 that we take care as we did in past when I was in TC from Tokyo and was ok to attend ni my mid night 16:13:35 I just meant informally ask if the time now works for people 16:13:47 because it's a lot of work to fill out 75 timeslots 16:13:52 I know because I did it 16:13:53 I am ok with that too. 16:14:15 I also don't realize if it's with with summer time or not, as it's transforming time to current timezone... 16:14:23 new members jamespage is from which timezone? I think that can solve most of the question 16:14:34 Wednesday at 4am DST is marked as only acceptable to knikolla[m] and not to the other folks who have responded? 16:14:35 noonedeadpunk: i believe it is your current timezone 16:14:40 UTC now, GMT later 16:14:51 I'm assuming the doodle is in local time? 16:14:54 Yeah, so... I should like add 1h to any time picked, right? 16:14:57 s/local/UTC/ 16:15:06 It's in local timezone 16:15:07 JayF: wait, what? 16:15:16 noonedeadpunk: that explains so much 16:15:17 I thought it was local 16:15:19 And I can't change that to UTC 16:15:29 it better be local timezone or I have to change my submission. it's not clear to me if it's already DST-adjusted or not though 16:15:31 I was confused, noonedeadpunk set me straight 16:15:33 yeah, if it is in UTC then I voted all wrong 16:15:39 yeah, doodle thinks it is smarter than you are 16:15:49 that's part of the problem doing it in the middle of the DST shift, fwiw 16:15:50 dansmith: I bet it's not DST-adjusted... 16:15:59 dansmith: did you fill it out before the weekend? 16:16:09 and also part of the problem not just working off a delta from the currently acceptable meeting time 16:16:12 https://framadate.org/ is much simpler than doodle 16:16:12 rosmaita: no 16:16:55 rosmaita: europe hasn't switched yet, so I have no idea if it's showing them US-based DST or their own timezone 16:17:10 should be their local TZ 16:17:11 "does this time work for everyone" is even simpler than framadate :P 16:17:15 I'll note that of the 5 respondants (the number 4 wasn't including the author), not all 5 have marked the current time as acceptable AFAICT 16:17:33 So I don't think we should do an immediate vote on the current time and instead stick with the doodle 16:17:48 gmann: you marked $now as unacceptable? 16:17:48 We do have other items to talk about though so we should probably move on 16:17:57 yes, one of the reasons i used framadate.org for the security sig meeting time polls (aside from the fact that it's an open source service) is that you can basically hard-code the times, so in the poll i just say that the times are utc and then list explicit start/end times. it's more effort to set up, but avoids tz confusion from tools trying to be helpful and convert for you 16:18:21 Doesn’t work for me. But it didn’t work for me when you moved to it 16:18:21 fungi: ++ 16:18:33 dansmith: confused with it is after time change or not but I prefer not this time BUT ok to adjust my schedule given TC on priority 16:18:45 I'm going to move on, we should ensure all of us fill out the doodle, I'll try to see if I can figure out if it's DST-adjusted or not. 16:18:47 gmann: ack 16:18:59 Next up is... 16:19:04 #topic Gate health check 16:19:07 Do we have any updates on the gate? 16:19:21 load has been low lately, so it's hard to tell for sure, 16:19:33 damn it, I logged in to doodle and now it's even not local timezone.... 16:19:35 but definitely worlds better than a few weeks ago, IMHO 16:19:52 noonedeadpunk: heh, I avoided to login 16:20:00 yeah, it's better currently 16:20:03 yeah, did not see any frequent failure 16:20:08 there was some desire to backport the mysql memory fix to stable devstack.. as it seems like it's universally better 16:20:22 That's excellent to hear, and good timing :) Thank you for all the work everyone is doing to keep things moving 16:20:23 so we might want to also consider throwing that default on master, if gmann is ready/willing 16:20:27 ++ 16:20:28 stable/2023.1 gate/devstack setup is in progress. hopefully we will be able to finsih by th8is week #link https://review.opendev.org/q/topic:qa-2023-1-release 16:21:15 we're still fiddling with some node providers trying to squeeze more capacity out of our quotas too, in hopes of improving response times for jobs 16:21:23 (elodilles_pto was asking about backporting) 16:21:27 dansmith: let me finish the devstack setup etc most probably we are ok as stable/2023.1 on devstack exist but let's finish other setup and then we can flip the flag 16:21:37 gmann: okay 16:21:44 dansmith: backporting ? 16:22:09 gmann: yeah, elodilles_pto was asking to backport the mysql memory fix to earlier devstack because so many stable jobs are failing with OOM 16:22:17 and because it seems to have solved the problems on master 16:22:35 dansmith: you mean backporting 'default to True' 16:22:50 not necessarily, but backporting the ability to set it 16:22:57 like, to older stables 16:23:20 ohk, to older one. +1. i was confused as it is already in for stable/2023.1 16:23:27 sounds good to me 16:23:32 yeah, to like stable/zed 16:23:36 +1 16:23:37 (and probably earlier) 16:23:41 Thank for for finding that and doing all the good stuff for devstack keeping things running :) 16:23:49 maybe when they return from pto that'll get proposed 16:23:57 sure 16:24:00 I don't think there's anything else actionable for gate health check though, should we move on? 16:24:10 nothing else from me 16:24:14 #topic Virtual PTG Planning 16:24:29 March 27-31 is the virtual PTG. We are tracking TC topics in the etherpad here: 16:24:34 #link https://etherpad.opendev.org/p/tc-2023-2-ptg 16:25:13 we may want to continue the discussion on scheduling 'operator-hour' this time ? 16:25:31 this was left from last week meeting due to Time constraints 16:25:46 gmann: do you want to lead that discussion since I wasn't here last week? 16:25:58 sure 16:26:00 thank you 16:26:47 as you know we schedule the 'operator-hour' in last vPTG and it was mixed feedback. for few projects it was not productive and for a few projects it was good discussion 16:27:21 we did not see much attendance from opetrator thought but that may be because it was the first time 16:27:35 let me fetch the feedback etherpad 16:27:40 yeah, seems worth doing again at least one more time, just because of exposure 16:27:52 IMO there is value in providing the venue even if many operators do not take the opportunity to join us. Perhaps we can encourage more operators to attend? For instance, we can ensure we get a plug for it at the Antelope OpenInfra Live highlights session 16:28:01 meaning, people may have, over the last six months, realized they missed out and would be up for it this time with lots of warning 16:28:13 Isn't it a bit too late for that? 16:28:35 here is feedback #link https://etherpad.opendev.org/p/Oct2022_PTGFeedback#L32 16:28:38 As most projects have already agreed some timeframes when project members can present 16:28:47 Already sent MLs about timeslots booked... 16:29:02 noonedeadpunk: i donot think so. we need to book slots for those 16:29:33 I actualy was sad to see there're no operator hours this time, but it's less then 2 weeks left, so dunno 16:29:36 i agree with noonedeadpunk, it does seem kind of late 16:29:41 to avoid conflict in projects scheduling the operator hour on same time, TC booked the placeholder slots and asked projects to pick from those 16:29:49 i think we should push for this at the in-person PTG 16:30:18 Well, as a matter of fact, not everyone involved in project work have only vPTG in their schedules 16:30:20 I don't think projects need the full set of contributors there for operator hour 16:30:24 honestly saying I am not sure how many of community developers will be there in in-person PTG 16:30:31 even just a PTL or a couple of designates is likely sufficient to recieve feedback 16:30:37 especially given the historical lack of participation 16:30:52 gmann: and may be the same for operators 16:30:53 rosmaita++ but as an addition to this one, not instead of it 16:30:57 maybe because that also needs some promotion? 16:31:00 dansmith: yes 16:31:18 that is why we want to take vPTG benefits of having more attendance 16:31:37 ok, i didn't handle scheduling for this vPTG, didn't know the TC had already reserved slots 16:31:46 not yet 16:32:07 but I think we can book placeholder and ask project to pick which should be ok 16:32:21 and promotion can go in parallel 16:32:27 So it sounds like we agree there is value for vPTG having operator hour, but some concerns about logistics of scheduling it. I think gmann's proposal of booking placeholders and reaching out to projects is good, even if we're getting involved a little late. 16:32:44 gmann: do you mind owning that? reserving placeholders and emailing for PTLs to pick one? 16:32:50 it's also what we did last time 16:32:52 assuming there's some level of agreement? 16:32:55 JayF: sure I can do. 16:33:03 Is there any objection to that proposed course of action? 16:33:03 need to be more clear with messaging around that this time though, we had a lot of confusion last time with ptls rebooking operator hour slots into different rooms an dthen not removing the placeholders, and other teams trying to book the same times 16:33:07 yeah, if no strong objection 16:33:24 fungi: good point 16:33:25 fungi: yeah, and some projects booking three of them 16:33:36 yeah, we need to make sure of that. 16:33:46 gmann: what is the plan for where the operator hour happens? 16:33:58 I think asking projects to pick one is enough and they can ask operator to come in developes slot for any specific discussion 16:34:17 gmann: right I'm saying some booked three last time, so we should be clear *not* to do that :) 16:34:23 yeah 16:34:35 I do strongly recommend we time this so that projects have an operator hour nailed down before next TC meeting; which will enable us to plug it on the OpenInfra Live 16:34:45 if no strong objection then let me compose etherpad about it and will book placeholder in parallel 16:34:48 ok, so operators will join the dev team in the location where the dev team is meeting? 16:34:49 I haven’t heard anything back from or Kendall 16:35:03 rosmaita: yeah 16:35:05 rosmaita: yes, 16:35:08 rosmaita: last time, we booked a specific room for it -- e.g. zoom 16:35:42 yes, i think the argument at the time was that operators wouldn't want to have to hang up and dial into a different room for each session 16:36:05 last time we used the project rooms as I recall 16:36:11 yes, project room 16:36:21 many teams did because they rebooked the placeholders into their own rooms 16:36:29 and it was very easy to check 'where is cinder operator hour is and click to join' 16:36:38 With my PTL hat on; I'm happy to go wherever we need to to make it easiest on operators. I don't have a good insight into what that is though. 16:36:56 fungi: yeah maybe the placeholder confusion extended to the room confusion 16:37:00 but the placeholders all initially used a single room in order to reduce confusion for ops, it just ended up that the teams decided that wasn't important to them 16:37:30 fungi: gmann: Do we think a stronger statement about the value of keeping them in the same room/time as the placeholder will help avoid these situations? 16:37:37 or else the reason for using the same room for all ops sessions wasn't clearly enough communicated to ptls and they didn't realize it was intentional 16:37:41 * JayF was one of the confused PTLs who rebooked a thing last time; it won't happen for us again 16:37:47 man, that's not how I remember it at all, maybe I'm misremembering.. but I thought the placeholders were striped across available rooms and the intent was to rebook into the project rooms 16:38:05 JayF: I strongly prefer the operators coming to the project rooms, 16:38:27 in hopes they'll stay around for follow-on discussion instead of just having the ops discussions and then the whole dev team leaving 16:38:38 yeah, that is one of the goal for these sessions to have more operator join developers interaction 16:38:42 I prefer operators attend at all; if having it in the project rooms is a barrier to that I'm happy to have it elsewhere. If we don't think that's a barrier, I agree with dansmith 16:38:42 they did end up all over the place room-wise, but mainly because of rebooking into team-specific rooms 16:38:44 right exactly 16:38:52 otherwise it is more of ops-meetup 16:39:08 so let's make it clear about the project room booking this time to avoid that confusion 16:39:14 and shoot for project rooms 16:39:31 We have 5 remaining agenda items and 20 minutes; so we should try to come to an agreement here quickly lest we run the clock out. 16:39:35 the argument at the time was to make it feel more like the ops meetup for them, because they'd be hesitant to share if they felt like they were on someone else's "turf" from a room perspective 16:39:54 i think it was TheJulia making that argument during initial planning 16:40:04 fungi: that was one argument and we voted, the result being project rooms 16:40:06 dansmith: then we need to avoid placeholder ? 16:40:27 and ask project to book one slot for operator-hour but make sure no conflict with other related projects 16:41:07 gmann: I dunno, maybe we need a different way to expose the placeholder slots than putting them in a room they won't really be in.. the point is just to avoid conflicts between the projects 16:41:35 The real piece we need to agree on at a TC-level is if we want it booked in operator-hour-specific-rooms or in the project rooms 16:41:35 yeah, let me thing and put something on etherpad today and then we can add feedback if still any issue 16:41:39 yeah, if the plan this time is to intentionally book them into whatever room is most convenient for each project team, then i would avoid pre-booking generic placeholders 16:41:44 how we communicate that is a detail I'm happy to leave to gmann 16:41:50 but we do have to get this topic to a close 16:41:59 and once TC are happy then I can push it on ML 16:42:20 sorry but I need to drop earlier today. I will read through rest of the meeting log tomorrow morning 16:42:21 o/ 16:42:22 yeah, I think we can figure out a better way to do that and handle it 16:42:52 #agreed gmann will detail plan in etherpad for operator hour planning, and execute it if no objection brought after posting 16:43:00 thanks 16:43:00 Does that sound correct to you all? 16:43:24 Lets do try to get times nailed down by next week; we really extend our reach if we can get it on the youtube live 16:43:41 sounds good 16:43:44 +1 16:43:56 and i agree about getting it onto the openinfra live broadcast 16:44:05 Moving on then 16:44:13 #topic TC 2023.1 tracker status 16:44:19 #link https://etherpad.opendev.org/p/tc-2023.1-tracker 16:44:50 for my item, on checking status of projects, I'm fairly certain it's likely too large of a scope to end up successful. I'm willing to consider my item completed as researched and seen as unviable for now :( 16:45:08 which I think is the result of the other times something similar has been researched 16:45:19 it seems we have many items to finish but next cycle is about to start 16:45:40 I suggest we add a 2023.1 TC item carryover discussion to PTG 16:45:46 where we can triage, decide what should carry over and what shouldn't 16:46:15 and maybe have a better idea of overall TC-member-capacity when volunteering for items (I made this mistake myself last TC-PTG) 16:46:56 yeah we can do but many of them are already agreed and easy to finish but agree to re-iterate if we want to do those if not finished in this cycle (means no priority ?) 16:47:19 s/if not/or not 16:47:34 I guess I think of it sorta like, with PTG from a project perspective, there's "what we want to do", "what we agree is useful to do" and then the reality of "what we actually have time to do" 16:47:53 even items where we have a "yes" on the first two, we often have to revisit to ensure it's worth spending contributor capacity on vs new items that are coming up 16:48:17 I would assume we could take this same approach to TC items not completed in a cycle; re-evaluate priority against capacity and incoming items and ensure we still think it's the best use of time 16:49:45 sure, that make sense. and in next cycle tracker we can choose the one based on bandwidth available and priority of item 16:49:52 I've added it to https://etherpad.opendev.org/p/tc-2023-2-ptg 16:50:01 Is there anything else related to 2023.1 tracker status? 16:50:35 We have a topic next for cleanup of pypi maintainership on the agenda; is there action to take there, or is that a good candidate to push to next week since we're low on time? 16:51:01 I still see an occasional email indicating someone has made changes 16:51:26 I think you volunteer to send email about PTL asking maintainers to remove themself and give ownership ? 16:51:43 #topic Cleanup of PyPI maintainership 16:51:44 QA did that and all steps done now 16:51:52 #link https://review.opendev.org/c/openstack/governance/+/874787 16:52:07 that needs to land before any contact with PTLs can be made, I think it's eligible to merge right now 16:52:34 this is ready to merge now 16:52:37 If there's no objection; I'll ensure that lands after the meeting and take the action to notify PTLs to notify owners 16:52:51 #action JayF To notify PTLs about action-needed for PyPI maintainership cleanup 16:53:01 Sounds like this is on track then, good stuff \o/ 16:53:08 going to move on quickly so we can get thru the rest 16:53:19 #topic Recurring tasks check 16:53:25 #topic Recurring tasks check 16:53:27 #undo 16:53:27 Removing item from minutes: #topic Recurring tasks check 16:53:29 JayF: it will be good to add those extra or update steps in #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup 16:53:30 How do bare rechecks look? 16:53:43 slaweq had to leave 16:54:02 (so punt) 16:54:05 One week without the update won't be too bad :) 16:54:18 #topic Check in on voting for version names 16:54:24 #link https://review.opendev.org/c/openstack/governance/+/874484 16:54:26 and 16:54:31 #link https://review.opendev.org/c/openstack/governance/+/875942 16:54:52 feels like we can drop this from the (crowded) agenda to me at this point 16:54:53 are competing to change the status quo of how we reference versions; if you have opinions please comment in the reviews and/or place a Rollcall vote on them 16:55:01 dansmith: yeah, until PTG you're likely right 16:55:03 moving on 16:55:04 doesn't seem like there's intertia 16:55:11 #topic Open Reviews 16:55:16 #link https://review.opendev.org/q/projects:openstack/governance+is:open 16:55:41 We have a handful of governance changes that have been updated recently, please review them and place votes on them. 16:55:46 I'll be looking at them after this meeting myself. 16:56:03 Is there anything further for the TC meeting? 16:56:30 nothing from me 16:56:43 Thank you all for being cooperative and helping me through chairing my first meeting; I'm happy to accept feedback in DM if there is any. 16:56:45 #endmeeting