Tuesday, 2024-04-23

opendevreviewGhanshyam proposed openstack/governance master: Add option to move leaderless project to Inactive status  https://review.opendev.org/c/openstack/governance/+/91472603:07
*** elodilles_pto is now known as elodilles07:01
*** gthiemon1e is now known as gthiemonge07:46
slaweqgouthamr hi, I just want to let you know that I will not be able to attend today's meeting because I have dentist appointment with my daughter at the same time14:13
gouthamrslaweq: hey, thanks for letting me know!14:50
opendevreviewGhanshyam proposed openstack/governance master: Move distributed-project-leadership model into doc  https://review.opendev.org/c/openstack/governance/+/91682217:43
opendevreviewElod Illes proposed openstack/openstack-manuals master: Re-add project data for 2023.1 Antelope  https://review.opendev.org/c/openstack/openstack-manuals/+/91682317:43
opendevreviewElod Illes proposed openstack/openstack-manuals master: Re-add project data for 2023.1 Antelope  https://review.opendev.org/c/openstack/openstack-manuals/+/91682317:47
JayFgouthamr: I'm going to forward you an email which contains the hostkey + meeting link for the OpenStack TC zoom meeting room17:49
fungiclosest thing to an actual sceptre you had, as it turns out17:50
JayFyeah but it's weird because I had a personalized sceptre the whole time (zoom pro acct)17:50
fungishh, don't let anyone hear you. they'll ask you to host more meetings!17:51
* gouthamr :D yikes17:52
gouthamrJayF thank you.. 17:52
gouthamri think i goofed up the reminders17:58
JayFI've also invited gouthamr to be an owner of the openstack-tc YT channel as well17:59
JayFI'll note myself, knikolla, and gmann also retain owner privs on that account is backup is ever needed18:00
gmannthanks, I was going to do that.18:00
gouthamr^^ ++18:00
gouthamr#startmeeting tc 18:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:00
opendevmeetThe meeting name has been set to 'tc'18:00
gouthamrhello everyone; welcome to the weekly meeting of the OpenStack Technical Committee18:00
gtemaO/18:01
gouthamrJayF 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 case18:01
gmanno/18:01
gouthamr#chair JayF 18:01
opendevmeetCurrent chairs: JayF gouthamr18:01
gouthamrA reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct18:01
dansmitho/18:01
JayFo/18:01
gouthamrToday's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee18:01
gouthamr#topic Roll Call18:01
frickler\o18:02
gouthamrslaweq is away today18:02
JayFo/18:02
gmanno/18:02
gouthamri haven't seen any other absences here, on the ML or on https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee18:02
gouthamrso a reminder, that you can use these forums to tell us you can't be here during these meetings18:03
noonedeadpunko/18:03
* gouthamr does mental math.. 18:05
gouthamrquorum checks out; lets continue18:05
gouthamr#topic TC vPTG 2024.218:06
gouthamrthank you JayF for compiling a summary for the openstack-discuss mailing list18:06
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/MHP3MMS7Z6DJK7EAXAIDWDK3DU4ZXELK/ ([tc] TC vPTG 2024.2 Summary / Notes)18:06
gouthamrwe have identified several action items; and we can start checking on these during this meeting, and in future meetings18:07
gouthamrseveral governance changes are being proposed, and many of these are follow ups from the TC discussions at the PTG.. 18:08
gouthamri'll take note to revisit this until we have ack'ed all our AIs18:09
gouthamrdoes anyone want to bring up anything specific wrt $topic18:09
fricklerI want to mention the unmaintained transition for zed18:09
gouthamr+118:10
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/WIEIJVVBD36RBHP2MP4BWW4F5SFPK4FA/ ([PTL][release][stable] Transition Zed to Unmaintained)18:10
frickler#link https://review.opendev.org/q/topic:%22zed-unmaintained%2218:10
fricklerdidn't we want to decide about eoling the older branches first?18:10
spotz[m]o/ Sorry!18:11
gmannI think, we should but giving some time of around 1-2 months after the announcement in ML18:12
fricklerI 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 shape18:12
gmannI think elodilles already made the ML announcement about that ?18:12
fricklergmann: so should we delay transitioning zed until after that period?18:12
noonedeadpunkwe just started looking on current unmaintained branches after the ptg18:12
noonedeadpunks/we/in osa we/18:12
gmannfrickler: I am ok either way delay or go in parallel 18:12
noonedeadpunkand capacity of unmaintained team is also really a question18:13
fungiit's still unclear to me why control of "unmaintained" branches would need to be so restricted18:13
fungithought that was part of the point of saying they're unmaintained18:13
dansmithme too18:13
noonedeadpunk+118:13
fricklerthe point is to eol them once they are no longer cared for18:14
noonedeadpunkthough, I also miss a process for teams to "subscribe" for caring for18:14
gouthamr+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 in18:14
fricklerand thus to get rid of broken CI jobs and zuul config errors18:14
gmannNOTE: these all old unmaintained branches we kept for migration to new model otherwise they have been in EM state for long right18:14
spotz[m]I'm assuming because it has to pull off a list from somewhere?18:14
fricklerand I don't see that happening18:14
fungithere still seems to be a hesitance to just eol things when nobody responds18:15
gmannI am ok to get rid of these old EM->unmaintianed branches to EOL soon if no clear interestr18:15
noonedeadpunkfungi: well, user survey is not least factor in that I guess18:15
JayFfungi++18:16
gmannand from SLURP moving to unmaintained we anyways will keep them for 1 year at least by default unless explicitly opt-out18:16
noonedeadpunkLike Yoga is still one of the biggest used versions18:16
frickleruser 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
fungibranches 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
noonedeadpunkwith 2023.1 being jsut 7%18:17
JayFWe 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:17
gmannwe should modify this question now to convey the unmaintained model to them18:18
JayFIf 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
gouthamr^ +118:18
noonedeadpunkfrickler: I guess I more meant - that we need more time to spread information about changed process18:18
gmannand there is no such thing called 'community support' for older branches18:18
noonedeadpunkLike 6 month ago we had rocky in EM and today we're EOLing Zed18:18
JayFWe are the leaders of OpenStack; sometimes that means leading by showing the good path and EOL'ing the bad paths.18:18
gouthamrnoonedeadpunk: clarification, no we aren't EOLing Zed18:19
noonedeadpunkRegular people not really reading all TC decisions18:19
noonedeadpunkgouthamr: sorry, moving to unmaintaned18:19
JayFnoonedeadpunk++18:19
noonedeadpunkLike for some it's still supririse that OOO died :D18:19
noonedeadpunk(not saying we should care for those, jsut pointing out communication issues)18:20
gmannwhole 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 EOL18:20
fungii 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
fricklerwhat I see is people saying "we want to maintain this" and then nothing happening in terms of actual work18:20
noonedeadpunkthere's not much point maintiaining Glance when Nova is EOLed18:21
gouthamrtrue; can we make the call to EOL victoria atm? and put out a proposal suggesting a faster EOL for other branches? 18:21
noonedeadpunkWell, I guess I'm just saying we've become too agressive in eoling too quickly18:21
fungimy expectation is that if nova's unmaintained/yoga branch doesn't have caretaker volunteers, it's unlikely glance will either18:21
noonedeadpunkthat'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 basically18:22
fungiand the new policy is to eol unmaintained branches with no explicit volunteer caretaker opt-in18:22
spotz[m]I think it would be more a fly by fix from someone using it18:22
opendevreviewGhanshyam proposed openstack/governance master: Add DPl model & liaison reset policy  https://review.opendev.org/c/openstack/governance/+/91683318:23
gmannok, we have two quesions here18:24
JayFspotz[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
JayFspotz[m]: not to mention recurring items like CI maintenance :/18:24
gmann1. any objection to move zed to unmaintained18:24
gmann2. EOling the existing unmaintained18:24
* gouthamr sets a ticker on this issue.. 18:24
noonedeadpunkJayF: I have some doubts who outside of old Fuel-based Mirantis deployments were really using it...18:25
noonedeadpunkThough 21% of deployments being on Yoga specifically is quite evidential data18:25
spotzjayf Oh no I agree - I'm just thinking that's how a fix might get submitted in the Nova/Glance example given18:25
gmannfor 1 (moving zed to unmaintained ), i think there should not be any blocker as per the timelines18:25
spotz[m]FYI Matrix and IRC are out of sync:)18:25
* gouthamr ohmergod18:26
gmannand whether we EOL older unmaintained or not can wait more if we see any response on elodilles email18:26
gouthamri like gmann's proposal here.. 1) moving zed to unmaintained follows our existing process since we have yet-another-stable-branch that showed up18:26
gouthamrand i support disconnecting it from (2) - which is also an opportunity to give ourselves less work given we have a mess of unmaintained branches18:27
JayFSomething that might help bring clarity here18:27
JayFwe talk about EOL'ing older branches as a unified thing, but many projects may have already EOL'd them in some cases18:27
JayFIf 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 projects18:28
noonedeadpunkactually. talking about that. it;s also a bit annoying, that not all projects follow same releasing process despite being on the same release policy18:29
gouthamrdifferent problem? 18:29
gmannwhich has been case for long time or since starting18:29
noonedeadpunklike one would expect to have EOM and EOL tags for, say, Yoga when no unmaintained/yoga exist? But it's not always a case18:29
gouthamrah; that seems like an omission.. 18:30
noonedeadpunknah, it's just project moved to EOL before we made EOM...18:30
gmannand 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
JayFgmann++++++ extremely agree with that18:31
gouthamrhaha; that seems like a nice way to move on to other discussion items here and take this to long form18:31
gouthamrfrickler: we don't have a conclusion here, but, i would like to encourage a discussion on the channel or the ML once we wrap up18:32
gmannI 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/EOL18:32
fricklerI would agree if there were no zuul config errors18:32
fricklerbut I also agree that we should move on for now18:32
gouthamrany 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
gouthamrgoing once.. thrice.. 18:33
gouthamr#topic 2024.2 TC Tracker18:33
gouthamr#link https://etherpad.opendev.org/p/tc-2024.2-tracker (Technical Committee activity tracker)18:33
gouthamr^ the vast emptiness of our tracking :) 18:33
gouthamr /jk18:34
gouthamrplease help throw items in that we'd care about for this release cycle (and a bit beyond) 18:34
gouthamri 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 meetings18:35
gouthamrsince you'll share your thoughts directly on the etherpad18:35
gouthamr#topic Ongoing business18:35
gmann++18:35
gouthamri'd like to close out on things that JayF (and others) kicked off a formal-vote on18:36
gouthamr#link https://review.opendev.org/q/topic:%22formal-vote%22+status:open (Open Formal Vote items) 18:36
gouthamri'd like us to tackle the attention that the freezer items have been getting18:37
spotzI wouldn't mind working through https://review.opendev.org/c/openstack/governance/+/915021 so we can move forward18:37
gouthamr#link https://review.opendev.org/c/openstack/governance/+/915727 (Assign Dmitriy Rabotyagov as Freezer PTL)18:37
gouthamr#link https://review.opendev.org/c/openstack/governance/+/914911 (Transition Freezer project to DPL)18:37
gouthamrnoonedeadpunk: would you like to share anything wrt these?18:38
gouthamrare you leaning towards dropping https://review.opendev.org/c/openstack/governance/+/915727 yourself?18:38
noonedeadpunkwell... I've discussed it for a while now18:38
gouthamryes, you have the plank for 30 more seconds :) 18:39
noonedeadpunkAnd I think that DPL model might be more beneficial right now to onboard new core team18:39
gmannI prpoposed the DPL liaison monitoring things in this #link https://review.opendev.org/c/openstack/governance/+/916833/118:39
gmannnoonedeadpunk: ++18:39
gouthamr#link https://review.opendev.org/c/openstack/governance/+/916833/18:39
noonedeadpunkthough 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 well18:39
gmannbut irrespective of that I do not see why we are not giving go ahead to freezer DPL mode18:40
gtemaI honestly doubt dpl have any impact on onboarding new cores, neither is ptl18:40
noonedeadpunkI was just reading thorugh it18:40
gouthamrnoonedeadpunk: ah; ty... i'm hoping JayF will pitch into gmann's proposal here: https://review.opendev.org/c/openstack/governance/+/916833/18:40
noonedeadpunkyou can make ppl more important and repsonsible by giving them dedicated roles in project18:40
noonedeadpunkand keep involved18:40
gmannand having DPL model or PTL model does not means we can move it from Inactive state. that need a lot other activities to check18:40
JayFPlease don't not-merge a thing just because a single tc-member (me, in this case) has a -1 on it18:41
noonedeadpunk(or me)18:41
gouthamrnoonedeadpunk: you'll be first among equals whether you're PTL or leader of DPLs (lol, just introduced a new governance category)18:41
JayFand I suspect, after reading gmann's proposal, that I'll likely flip the vote on that DPL proposal once his gets momentum and some feedback18:41
gtemaYou can't motivate non existing ppl interested in project18:41
gouthamrperfect; ty for looking 18:41
noonedeadpunkgtema: so who told you they're non-existent?18:41
gtemaOtherwise this would not end in the current situation 18:42
noonedeadpunkI do have communication with couple of orgs about their participation18:42
noonedeadpunknot all of them just decided about migration to openstack. and having DR is quite a contributing factor to that decision18:43
gouthamrnoonedeadpunk++ good stuff; i understood gtema's remark to be general18:43
noonedeadpunkIt won't happen overnight, but well18:43
gouthamrthanks for persisting.. 18:43
noonedeadpunkthere's interest at least18:43
gmannnoonedeadpunk: interesting. I have done PoC on freezer long back in 2018 i think. but that time it was not so ready or perfect18:44
gmannand it did not fit in our customer requirements18:44
noonedeadpunkI did around same time as well.... 18:45
gmannbut do not know the current status and seeing interest in this is good18:45
noonedeadpunkEventually, most "interest" is around some scheduler for cinder-backups more or less as well as lifecycle18:45
gouthamri 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
JayFgmann: 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
noonedeadpunknot client agent part18:45
JayFgmann: re: POC of a project just not fulfilling requirements18:46
gouthamrif you intend to abstain from a vote, please let us know again by commenting as such18:46
gouthamrif you don't already use it, there's a link to this useful dashboard in our TC documentation18:47
gmannJayF: 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 too18:47
gouthamr#link 18:47
gouthamrhttps://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-change18:47
gouthamr+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
gouthamrugh18:47
fungithat's one heck of a url18:47
spotz[m]eww18:47
JayFI'll note many of those dashboard links (even when not mangled by IRC) require login to work18:47
gmannnoonedeadpunk: ohk, I was looking more on client-agent things18:47
noonedeadpunkthis part is very questionable still....18:48
gouthamrtrue 18:48
gmannk18:48
gouthamrspotz[m]: i didn't ignore your link earlier18:49
spotzI'm so out of sync following on IRC and Matrix:)18:49
gtemaYeah, matrix today sucks18:50
gouthamr#link https://review.opendev.org/c/openstack/governance/+/915021 (Update to include docs and miscellaneuos repos for AC status_18:50
gouthamr^ i'll copy some folks; but please ack this review as well.. 18:50
gmannI think I left comment there which is still not answered or resolved18:50
gmann;et me check18:50
gmannlet18:50
gouthamri'll follow up on this channel with some more review concerns18:50
spotzYou were answering a lot of the concerns gmann so if I missed one you had let me know18:51
gouthamrmoving on.. 18:51
gouthamr#topic 2025.1 Elections18:51
gmanngouthamr: many of them might be eligible to merge18:51
gouthamrgmann: ack; i'll catch up and help move these 18:51
gouthamrsooooo, sorry to drop this topic in this early18:52
* JayF wonders if gouthamr has been introduced to `tox -echeck-review-status` :D18:52
gmannspotz: I think discussion going on there. other also have some point. I need to check if anything pending on me answer/reply18:52
fungiwell, 2025.1 elections will be happening in 2024 ;)18:52
spotzYeah it's gotten a bit confusing18:52
gouthamrbut, 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 time18:52
gmannJayF: I think yes. this is great help for chair and magic script 18:52
gouthamrbut, we crawl before we walk18:52
JayFgmann: did you make the magic script? If so consider this a belated thanks :D 18:53
gouthamri was going to put out an early call seeking election officials for the 2025.1 elections18:53
fungithe earlier the better with election scheduling18:53
spotzSo we can keep reminding folks to submit18:53
gouthamr++18:53
JayFAre those election dates set yet? It's hard to know if I can volunteer without being able to compare to a calendar18:53
gmannJayF: not me. I think doug or ttx or mnaser maybe and later on it was fixed/amend it to improve. 18:54
gouthamror point them to it when they say they were only looking at the [$project] emails on openstack-discuss and missed [election]18:54
spotzJayF: A lot of them are hard coded in with the release schedule18:54
JayFack, I'll check offline18:54
gmannon election, we need TC member to liaison to monitor election deadlines/etc18:54
spotzWell you have to tell the script the date to base it's dates off of but..18:55
JayFI may be willing to be that volunteer need to check schedules as I have a busy second-half of the year18:55
mnasercheck-review-status was blessed to me by doug :)18:55
gmannI am, not sure if anyone volunteer fot that18:55
gmann++18:55
JayFspotz: even doing like "what were this election deadlines +6months)18:55
gmannmnaser: ++. that is really helpful  to all chairs18:55
spotzjayf yeah it should be able to, it won't send generate emails but we can get the dates from it to publish ourselves18:55
gouthamrElections last time were in the R-2 week18:57
gouthamrand per our charter, its the latest we can hold them18:57
fungiat least gives you an opportunity to see if it's falling across events or majoy holidays18:57
gmanndeadline as per charter is election to be held between R-3 to R-8 (i will confirm again)18:57
gouthamrThese 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:57
gouthamr^ excerpt from https://governance.openstack.org/tc/reference/charter.html#election-for-ptl-seats18:58
gmann(between ‘R-8’ and ‘R-2’ week). gouthamr ++18:58
gouthamrSo extrapolating that, Sep 16-Sep 20th can be a candidate for the election week; once we have election official volunteers we can finalize this18:59
gouthamrwe're T-1 minute to wrapping this up19:00
gouthamrhaha19:00
fricklerdon't we have 2 week elections now?19:00
gouthamralright we're at time; but we can continue the after-discussions in this channel and ML19:00
gmannyes, 2 week nomination and 2 week poll19:01
gouthamrsorry we didn't have open discussion today19:01
spotzWeel for campaigning and a week to vote19:01
gouthamrthank you all for attending and for the spirited discussion19:01
gouthamr#endmeeting19:01
opendevmeetMeeting ended Tue Apr 23 19:01:33 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:01
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2024/tc.2024-04-23-18.00.html19:01
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2024/tc.2024-04-23-18.00.txt19:01
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2024/tc.2024-04-23-18.00.log.html19:01
noonedeadpunkthanks gouthamr !19:01
gmanntwo week to vote not 1 week19:02
gouthamr+119:02
gmannthanks19:02
gouthamrtc-members (and everyone): if you'd like to volunteer to be election officials, please let me know 19:02
* gouthamr cross posts this on #openstack-dev19:03
gmanngouthamr: there are two thing 1. TC member liaison to monitor if election are happening on time or any blocker/issue 2. election official who can be TC or any non-TC and any number of election official is ok.19:04
gouthamrfrickler spotz gmann: https://governance.openstack.org/election/process.html has more of the specifics on selecting election dates.. i think we've favored combined elections 19:04
gouthamrso there's an overlap that we'd work out19:04
gmannTC member liaison can be election official though if not running in that election 19:04
fungihaving spent years officiating elections after i stepped back from the tc, i'm happy to help mentor volunteers for it too19:05
spotz[m]I need to figure out work travel for August/September first. And yeah we've been doing combined the last 3 years atleast19:05
fungikeep in mind that the openinfra summit in korea is happening around that timeframe too19:05
gouthamri missed this19:06
spotz[m]I think Ian might be the only current/recent Election Official who's done the CIVS part19:06
gmanngouthamr: yes and I have modified the election tooling to make sure generated dates by election scripts are as per charter19:06
gouthamrgmann nice19:06
gmanngouthamr: so both are in sync for now and most of time with combined election19:06
gouthamr++ definitely more convenient19:06
gmannbut considering spotz propose for AC modification need them to update19:06
fungigouthamr: if you mean you missed the summit announcement, it's september 3-4: https://openinfra.dev/summit/19:07
gouthamrfungi++ ty19:08
fungibut maybe you mean you missed that we started combining tc and ptl election schedules. yes very convenient19:08
gouthamrnope the summit dates19:09
spotzAnd the CFP is open:)19:09
gouthamrlike you suggested, we can consider this when planning the election dates and allow an extra week with whatever we're doing during that week19:09
gmannonce we started combined election, we continued that in all elections and did not have separate one. this is good considering election officials number and work.19:09
fungiokay, yes, so summit is in suwon which is basically a suburb of seoul19:10
fungibut anyway, with longer nomination and polling periods, event dates and holidays are less of a concern19:11
gouthamragreed19:29
spotzAnd PTO quite a few missed deadlines because they were away19:30
opendevreviewGhanshyam proposed openstack/governance master: Add DPL model & liaison reset policy  https://review.opendev.org/c/openstack/governance/+/91683319:37
gmannJayF: noonedeadpunk tc-members ^^ updated DPL reset timeline to 6 months. Initially I wanted it to be 1 year but 6 months make sense especially seeing inactive projects are being detected very late.19:38
gmannat least provide less window for project to misuse DPL model to hide their inactivity 19:41
JayFI wouldn't even ascribe any deliberateness to it. Just people get busy and openstack is often the least-squeaky wheel in their job :/19:42
opendevreviewElod Illes proposed openstack/openstack-manuals master: Re-add project data for 2023.1 Antelope  https://review.opendev.org/c/openstack/openstack-manuals/+/91682320:44
opendevreviewGhanshyam proposed openstack/governance master: Add DPL model & liaison reset policy  https://review.opendev.org/c/openstack/governance/+/91683322:14

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