| gouthamr | tc-members: a reminder that there's no 0800 UTC meeting today, we'll be catching up at 1700 UTC | 06:27 |
|---|---|---|
| mnasiadka | yay | 06:29 |
| elodilles | gouthamr: hi, about which deliverables haven't merged any patch since latest release, here is a list: https://paste.opendev.org/show/bFgORyYfUF5yifps7uYW/ | 08:08 |
| elodilles | (though, 2 of them is falsly listed: glance-store and openstack-ansible-roles. but the others should be correct) | 08:09 |
| elodilles | (the command is in the openstack/releases repository) | 08:09 |
| gouthamr | tc-members: a gentle reminder that our weekly irc meeting will be held here in ~50 minutes | 16:09 |
| gouthamr | elodilles: late ack, ty! that also probably explains the lack of acks from the barbican release managers/ptl for the hsm repos: https://review.opendev.org/q/topic:%22gazpacho-rc1-deadline%22+status:merged+hsm | 16:59 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Mar 17 17:00:57 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| gouthamr | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 17:01 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| dansmith | o/ | 17:01 |
| bauzas | o/ | 17:01 |
| noonedeadpunk | o/ | 17:02 |
| dansmith | I guess it's well-known that the ics feed does not have the meeting today/now? | 17:02 |
| gouthamr | dansmith: yes.. because we moved the 0800 UTC meeting to 1700 UTC and just informed folks here and via email | 17:02 |
| spotz[m] | o/ | 17:03 |
| gouthamr | it was tedious to update the ics, we might end up changing the whole thing in a couple of weeks | 17:03 |
| frickler | \o | 17:03 |
| gouthamr | courtesy-ping: cardoe, mnasiadka | 17:03 |
| fungi | irc-meetings generates an ics file based on what's configured for your meeting, and serves it from meetings.opendev.org | 17:03 |
| gouthamr | noted absence: t o n y b | 17:04 |
| mnasiadka | o/ | 17:04 |
| * gouthamr hasn't heard from tonyb here in a few weeks.. despite the tagging last week | 17:04 | |
| gouthamr | fungi: yes, i'll be updating irc-meetings when we have consensus on the new meeting time.. last week, we decided to stick to Tuesdays at 1700 UTC until the end of March. | 17:05 |
| spotz[m] | He was at the board meeting last week | 17:06 |
| gouthamr | (this meeting's the only outlier, the ICS should be fine for next week) | 17:06 |
| fungi | and showed up in opendev matrix yesterday | 17:06 |
| gouthamr | ah, ty he's been spotted somewhere | 17:06 |
| gouthamr | no TC activity has been noted... | 17:07 |
| gouthamr | tonyb: i don't want to tack on more than you're probably dealing with at the moment... but, we've some AIs that'll probably need re-assignment if you're away.. | 17:07 |
| gouthamr | a reminder that you can edit https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee and add your absence there, or just leave a note here regarding unavailability if you anticipate it.. | 17:08 |
| dansmith | gouthamr: I will miss next week | 17:09 |
| gouthamr | dansmith: ack, ty for letting me know | 17:09 |
| dansmith | and the following actually | 17:09 |
| gouthamr | #topic Last week's AIs | 17:10 |
| gouthamr | dansmith: noted | 17:10 |
| gouthamr | we've updated the chair/vice-chairs on the TC roster: | 17:10 |
| gouthamr | #link https://governance.openstack.org/tc/#current-members | 17:10 |
| gouthamr | no liaison changes were needed because VMT liaisons continue from the last cycle: | 17:11 |
| gouthamr | #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management | 17:11 |
| fungi | thanks! | 17:12 |
| gouthamr | and the rest of the DPL liaisons are in projects.yaml: | 17:12 |
| gouthamr | #link https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml | 17:12 |
| gouthamr | spotz[m]: would you submit a change to the election repo to reset the election liaison, here's where it is: | 17:12 |
| gouthamr | #link https://review.opendev.org/c/openstack/election/+/964733 | 17:12 |
| gouthamr | that's all about liaisoning | 17:13 |
| frickler | isn't sahara retired? (re VMT) | 17:13 |
| gouthamr | yes it is | 17:13 |
| gouthamr | next are a couple of AIs regarding leaderless teams | 17:14 |
| gouthamr | the election results are due tomorrow, you'll see PTL updates for nearly 40 project teams posted, we'll need a few eyes to merge them | 17:15 |
| spotz[m] | Yeah I’ll get that in an bit | 17:15 |
| gouthamr | ty spotz[m] | 17:16 |
| gouthamr | we've some more to discuss around the retirement of venus and vitrage - a release concern, we'll get to that in a sec | 17:17 |
| gouthamr | i just wanted consensus that we'll be fast-tracking the merges on the other appointment changes here: | 17:17 |
| gouthamr | #link https://review.opendev.org/q/hashtag:%222026.2-leaderless%22+(status:open%20OR%20status:merged) | 17:17 |
| gouthamr | i don't see any negative votes or concerns expressed in these gerrit changes | 17:17 |
| gouthamr | so, if you'd like to note your approval, or disapproval please do so asap.. once the result changes are posted, i'll rebase these and merge them based on the approvals so far | 17:18 |
| gouthamr | any concerns with this? | 17:18 |
| noonedeadpunk | there was an email in the morning about masakari situation | 17:19 |
| noonedeadpunk | and I see that appointment patch is missing so far. | 17:20 |
| noonedeadpunk | I think it makes sense to reply to the thread with TC hat on about proposed options | 17:20 |
| gouthamr | maybe i need to clarify that the election result change will tag each of these "leaderless" project teams with an "APPOINTMENT NEEDED" annotation. that's why a rebase is necessary, so it's just process, i don't want to delay these another week since we've had enough soak time.. | 17:21 |
| gouthamr | noonedeadpunk++ | 17:22 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/C2BQ7UAJPPEEY2Q5TKJETG7DSKGVMHXT/ | 17:22 |
| gouthamr | tl;dr: we're being asked for advice on whether to allow a past PTL to take over the reigns temporarily while the team reforms, or if we think DPL is better | 17:23 |
| noonedeadpunk | tbh, I am not sure what is better | 17:24 |
| dansmith | not a past PTL of that project, but past PTL in general? | 17:24 |
| gouthamr | ah, an ex-PTL of OpenStack Blazar Project, ex-Core reviewer of OpenStack Congress Project per some social bio | 17:25 |
| dansmith | but ... mentoring a new PTL, if that's really going to happen, seems like an excellent opportunity.. hate to not capitalize on that | 17:25 |
| mnasiadka | I’m a bit hesitant to say that DPL for a project that has problems nominating a PTL is going to end well | 17:26 |
| dansmith | yeah ^ | 17:27 |
| noonedeadpunk | well, the main problem with nominating ptl was lack of time for all ptl activities from all interested parties | 17:27 |
| noonedeadpunk | so DPL kinda aims to solve that by splitting responsibilities | 17:28 |
| gouthamr | we'd prefer an active contributor/maintainer to take on the role, and would welcome mentoring? | 17:28 |
| mnasiadka | noonedeadpunk: in my mind - there’s a problem to find one person that will take the responsibility (he doesn’t need to do all PTL activities - he can delegate) - are you sure we’ll find three in reasonable time? | 17:29 |
| noonedeadpunk | it's also more if PTL has any awareness of the project, as from what I got, they are more have a general governance knowledge | 17:29 |
| gmaan | DPL for less active team is always risky, maybe we should remove that options from leaderless projects available options | 17:30 |
| mnasiadka | gmaan:+1 | 17:30 |
| gouthamr | gmaan: woah, that'd affect oslo | 17:30 |
| noonedeadpunk | ++ | 17:30 |
| gouthamr | (and requirements) | 17:30 |
| noonedeadpunk | (and potentially more things) | 17:30 |
| gmaan | oslo is less active for sure but still have folks around but i do not disagree on that | 17:30 |
| mnasiadka | Sure, but wouldn’t it raise visibility on the problems we have as a community? | 17:31 |
| gmaan | ++ yesh that one | 17:31 |
| noonedeadpunk | masakari have folks around as well, but not really confident enough in themselves to drive the project | 17:31 |
| noonedeadpunk | so eh, this is so-so argument | 17:31 |
| noonedeadpunk | anyway | 17:31 |
| fungi | glance had a ptl who wasn't even a core reviewer on the project, so i don't know that it holds generally? | 17:31 |
| noonedeadpunk | I am not saying we should prefere DPL for masakari, it's just every approach has it's ups and downs | 17:32 |
| noonedeadpunk | but indeed, I think it's simpler to get a PTL if there's somebody ready to step in | 17:32 |
| noonedeadpunk | I think nova has/had same | 17:32 |
| dansmith | current nova PTL is not a core | 17:32 |
| gouthamr | yet? | 17:32 |
| noonedeadpunk | for couple of cycles already | 17:33 |
| dansmith | I thought the offer was for an experienced PTL to take the administrative role and mentor someone else who might be a candidate to take over | 17:33 |
| dansmith | core or not core, that seems like a very ideal situation if there is actually someone to mentor | 17:33 |
| noonedeadpunk | yeah, okay, agree | 17:33 |
| noonedeadpunk | makes sense when you put it this way :D | 17:33 |
| gouthamr | hmmm, i support this given we've had success with this approach in other teams | 17:34 |
| gouthamr | noonedeadpunk: would you be able to summarize this response then? | 17:35 |
| noonedeadpunk | yep, will do | 17:35 |
| gouthamr | ty noonedeadpunk | 17:35 |
| noonedeadpunk | about my AI for vitrage and venus retirement | 17:36 |
| gouthamr | yes, let's chat about that.. | 17:36 |
| noonedeadpunk | I was preparing patches, when realized - are we sure we wanna do retirement, and not deprecation? | 17:36 |
| gouthamr | noonedeadpunk: "inactive" was a kind of deprecation.. the hope was we'd not publish releases | 17:37 |
| gouthamr | but, we've had a hiccup there | 17:37 |
| noonedeadpunk | as retirement would limit us in proposing any security patches | 17:37 |
| gouthamr | #link https://review.opendev.org/q/topic:%22gazpacho-rc1-deadline%22+status:open | 17:37 |
| fungi | deprecation would be fine though | 17:37 |
| noonedeadpunk | deprecation also prevents projects from releasing | 17:38 |
| fungi | you only need security fixes on maintained stable branches once deprecated | 17:38 |
| noonedeadpunk | ++ | 17:38 |
| gouthamr | ^ a release for venus and vitrage was tagged earlier in the release, and we're trying to avoid that happening with the coordinated release: | 17:38 |
| gouthamr | #link https://review.opendev.org/c/openstack/releases/+/980900 (Remove vitrage and venus from 2026.1 Gazpacho) | 17:38 |
| gouthamr | is that our gap? would folks prefer seeing "inactive" project deliverables deprecated and moved to "legacy.yaml" - would that be a better indicator for the release team | 17:39 |
| noonedeadpunk | so I'd say that deprecation is potentially a better option overall as we still are able to keep stable branches at least without security issues | 17:39 |
| noonedeadpunk | though argument here, is that without PTL or security liason - who would be doing patching... | 17:39 |
| fungi | which is essentially what happened with murano | 17:40 |
| noonedeadpunk | though with evolution of LLMs, which are trained also on openstack source code, this becomes easier to handle... | 17:41 |
| gouthamr | hmm, most recently, with monasca, we were able to keep the project around long enough as "inactive", and then drop all the older stable branches alongside master.. but, we won't have that option all the time. | 17:42 |
| noonedeadpunk | at least I can take care of vitrage, as have an experience with it's code | 17:42 |
| fungi | i don't buy that, unless the llm-generated security fixes are any better than the llm-generated vulnerability reports we've been receiving | 17:43 |
| noonedeadpunk | I don't think we should keep as "inactive" | 17:43 |
| gmaan | in such cases of no maintainers for stable branches then it goes to retirement than deprecation. that is not ideal but actual visibility to operators/anyone thinking/relying on fact that stable branches are maintained | 17:43 |
| fungi | goes to retirements *and* we loudly warn operators/users to uninstall the software due to known unfixed exploitable vulnerabilities in the software | 17:44 |
| gmaan | yeah | 17:44 |
| noonedeadpunk | as deprecation removes it from releasing, and drops content | 17:44 |
| noonedeadpunk | but retirement leaves all stable branches "as-is" - isn't it? | 17:44 |
| fungi | deprecation shouldn't prevent it from releasing on stable branches from before the deprecation (until they reach end of maintenance) | 17:45 |
| gmaan | retirement delete everything including stable branches. depecation only do for master content | 17:45 |
| gouthamr | so splitting hairs here, we have a few maintainers for vitrage, but not for venus.. so maybe propose retiring venus and deprecating vitrage? | 17:45 |
| fungi | we've had stable point releases tagged on deprecated deliverables in the past anyway | 17:46 |
| gouthamr | basically, be explicit that the approach is motivated by availability of maintainers | 17:47 |
| noonedeadpunk | so basically that was the concern I wanted to raise | 17:47 |
| noonedeadpunk | I'm fine to proceed with any option we agree on | 17:47 |
| noonedeadpunk | but I think deprecation is a more user-friendly optiopn | 17:48 |
| noonedeadpunk | which also allows more easily to pick up maintenance if needed | 17:48 |
| noonedeadpunk | while makes state of affairs well-infromed by dropping master branch content | 17:48 |
| gouthamr | noonedeadpunk: ack. we should let openstack-discuss know, so if there are users in the wild that are interested to keep the lights on, they can step up.. | 17:49 |
| gouthamr | does anyone have strong opinions on this, besides noonedeadpunk? | 17:50 |
| JayF | I am +1 to the proposed plan. | 17:50 |
| spotz[m] | +1 | 17:51 |
| gouthamr | alright.. ty this was good to sort out. | 17:52 |
| gouthamr | I'll add my +1 to the release team's proposal here: | 17:52 |
| gouthamr | https://review.opendev.org/c/openstack/releases/+/980900 | 17:52 |
| gouthamr | you should too.. | 17:52 |
| noonedeadpunk | well, for instance, I can step in for stable branches of vitrage, but not master branches or keeping project active | 17:53 |
| gouthamr | ack noonedeadpunk | 17:53 |
| noonedeadpunk | I don't think these projects should be released anyway :) | 17:54 |
| gouthamr | ty, i think we've covered all of the election/leaderless concerns | 17:55 |
| gouthamr | anything else to talk about today wrt these? | 17:55 |
| gouthamr | we're jumping a bit on the agenda, but, that was my bad on the ordering of the topics | 17:55 |
| gouthamr | ty for taking all these AIs noonedeadpunk | 17:56 |
| gouthamr | #topic PTG | 17:56 |
| gouthamr | I've made some reservations and the etherpad is ready for your topics: | 17:56 |
| gouthamr | #link https://etherpad.opendev.org/p/apr2026-ptg-os-tc (TC PTG Etherpad) | 17:56 |
| gouthamr | we may not need 6 hours, but, i'll adjust that closer to the event.. but please do let me know right away if you have objections | 17:56 |
| gouthamr | i'm hoping to discuss community goals again, and discuss new ones (nox? pqc? :D) *ducks* | 17:57 |
| spotz[m] | I’m the only one who discusses ducks! | 17:58 |
| gouthamr | so if you're a goal champion, or know someone else who is.. please be prepared to do a rundown on where we are, and what else we need to do to.. | 17:58 |
| gouthamr | that's all i had about that, really.. | 17:59 |
| gouthamr | spotz[m]: i need some RDO ducks so i can sell them on ebay in 10 years | 17:59 |
| gouthamr | #topic A check on gate health | 17:59 |
| spotz[m] | There will be some for RH Summit | 18:00 |
| gouthamr | we don't have time for open discussion today, i know this has been a bad few weeks for us on CI.. just wanted to take a moment to thank folks for the firefighting | 18:00 |
| gouthamr | the websites going down repeatedly is affecting CI, developers, users and operators. There's no denying that.. we've had very little chatter about that on the ML.. but, if you're plugged into IRC or opendev, you kinda know what opendev folks have been dealing with | 18:01 |
| spotz[m] | FYI I’ll be at Kubecon next week if anyone needs me to talk to anyone let me know | 18:02 |
| gouthamr | we're past the hour.. but, if you'd like to add anything further to the minutes, please do so now | 18:02 |
| gouthamr | alright, thank you all for participating | 18:04 |
| gouthamr | don't let the discussion stop.. | 18:04 |
| gouthamr | #endmeeting | 18:04 |
| opendevmeet | Meeting ended Tue Mar 17 18:04:28 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-17-17.00.html | 18:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-17-17.00.txt | 18:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-17-17.00.log.html | 18:04 |
| gouthamr | fungi: clarkb: i'm wondering if you were going to post on the MLs on the gate situation? lots of people are confused and just "recheck"-ing, some people are chiming on #openstack-infra and matrix | 18:06 |
| gouthamr | https://www.reddit.com/r/openstack/comments/1ruupac/opesntack_docs_down/ | 18:06 |
| gouthamr | and elsewhere ^ | 18:06 |
| clarkb | we have been responding to the people who have talked to us. I will not be posting to reddir | 18:07 |
| clarkb | 18:07 | |
| gouthamr | ofc not | 18:07 |
| fungi | i think the people on reddit know where to find us if they want to help out instead of just complain | 18:07 |
| clarkb | the tl;dr is we've expanded the size of the server and moved docs.openstack.org to a dedicated host | 18:12 |
| gouthamr | ah, ty.. curious if you're seeing any success with these: | 18:13 |
| gouthamr | #link https://review.opendev.org/q/hashtag:%22apache-waf%22+(status:open%20OR%20status:merged) | 18:13 |
| fungi | we've been using some of that functionality to track the ip addresses of abusers and block them temporarily, yes | 18:14 |
| clarkb | this seems to have helped but hasn't made the problem go away. I've recently identified a new behavior that I think may be contributing and have a change up to try and improve it too | 18:14 |
| fungi | also it increases the memory use on the server | 18:14 |
| fungi | https://opendev.org/opendev/system-config/src/commit/fb38bb1/playbooks/roles/static/files/50-docs.openstack.org.conf#L21-L44 | 18:16 |
| fungi | that's the current ruleset for docs.openstack.org | 18:16 |
| dansmith | gouthamr: added my upcoming absences to the wiki | 18:17 |
| dansmith | you need not remove me from the ping list on those days, I'll be far away from the computer that dings :) | 18:17 |
| gouthamr | ty noted dansmith | 18:17 |
| dansmith | fungi: clarkb: have you considered the proof-of-work project that sits in front? or are you hoping to just deal with the traffic because you want it scrape-able? | 18:18 |
| gouthamr | ty fungi clarkb.. is the new behavior patch this one? https://review.opendev.org/c/opendev/system-config/+/981009 | 18:18 |
| gouthamr | i think they are: https://review.opendev.org/c/opendev/system-config/+/980993 | 18:19 |
| fungi | dansmith: you mean have we thought about the obvious while dealing with these various swarms for about a year? ;) | 18:19 |
| dansmith | ouch | 18:20 |
| fungi | gouthamr: 981009 is going to see if we free up resources on the servers a little more effectively, apache ends up with a lot of workers hung on old requests which may be a symptom of other timeouts | 18:20 |
| gouthamr | ++ | 18:21 |
| fungi | dansmith: but yeah, anubis, haphash, iocane, et cetera... we've been trying to balance tools that get in the way of users with outages that get in the way of users | 18:21 |
| dansmith | ack, I hadn't seen any evidence of them when I've loaded the page so I wasn't sure... didn't mean to insult of course | 18:22 |
| fungi | up until this past week-ish it's not really been an issue, we've dealt with the problems through excluding requests with obviously made-up user agents, instructing non-abusive crawlers where to focus/how to go easy on us, etc | 18:22 |
| opendevreview | Merged openstack/openstack-manuals master: Change tenant_network_types to project_network_types https://review.opendev.org/c/openstack/openstack-manuals/+/977833 | 18:22 |
| dansmith | I've been fighting it personally for at least a year at this point | 18:23 |
| clarkb | dansmith: https://review.opendev.org/c/opendev/system-config/+/980993 fwiw I put this together earlier as well | 18:23 |
| fungi | the latest incident is a flood of requests from hundreds of thousands of client ip addresses, mostly in mobile provider networks all over the world, trying made-up urls brute-forcing to see if they can find previously unindexed content | 18:23 |
| dansmith | clarkb: ack | 18:24 |
| fungi | i'm pretty sure it's a massive bot army made up of backdoored phones | 18:24 |
| dansmith | clarkb: even cloudflare's "I am under attack" human check seems to be no match | 18:24 |
| fungi | yeah, a cdn would be no use in this case because every url they're trying is unique (made of of constructed permutations of path components from nearby urls) | 18:25 |
| dansmith | fungi: well, a CDN that attempts to block bots would help, if it could actually do that | 18:25 |
| fungi | maybe cloudflare's bot detector would flag them before ever letting those requests through, but i feel like this is organized crime trying to bypass cloudflare's mitigations | 18:26 |
| fungi | and also we'd end up paying for cloudflare and handing over the keys for our hosting to them and all of our user ip addresses and browsing behaviors with it | 18:26 |
| fungi | and finally admitting that it's no longer possible to operate a website on the internet without paying the knee-cappers protection money | 18:28 |
| dansmith | yep, I resisted having to do that for a long time, but ran out of options.. and it turns out, they're good but not quite as good as I had hoped | 18:28 |
| dansmith | but yep, http getting to be like mail | 18:28 |
| fungi | nothing ever is quite as good as we hope | 18:29 |
| JayF | dansmith: clarkb: fungi: fwiw I'm working with my downstream to try and get someone pointed at opendev to help implement anubis or a similar tech as well; I have no idea whatsoever how successful I likely am to be | 18:45 |
| JayF | we have a pretty big devops team at ISC (Insight Softmax is the consultancy that powers GR-OSS) and I'm hoping to peel a person or two away to help | 18:46 |
| fungi | i'm assuming that's not isc.org (the internet systems consortium) | 18:47 |
| JayF | https://insightsoftmax.com/ insight softmax consulting | 18:47 |
| JayF | (If you've heard about Arctos Alliance recently forming a community around Apache Aaron, that's "us" too) | 18:48 |
| JayF | **Arrow | 18:48 |
| fungi | not familiar with it, but sounds cool. i know the other isc from bind and dhcpd fame | 18:50 |
| JayF | and from kea infamy | 18:50 |
| JayF | :( | 18:50 |
| fungi | and also isc created my preferred permissive open source license | 18:50 |
| JayF | I tend to use MIT, which is functionally equivalent aiui | 18:51 |
| JayF | and allows me to not worry if I put that code in gentoo (gpl) or here (apache 2) | 18:51 |
| fungi | i assume you mean "mit/expat" ;) | 18:52 |
| fungi | (there's more than one mit license, after all) | 18:52 |
| JayF | https://codeberg.org/JayF/jaypardy/src/branch/master/LICENSE this one lol | 18:53 |
| JayF | I probably should use MIT0 or BSD0 but meh | 18:53 |
| JayF | (I know licenses by gentoo identifiers; the 0 is just the no-notice variations) | 18:54 |
| fungi | yeah, debian likes to differentiate between the "expat" license from mit (mit/expat) and the "x11" license from mit (mit/x) and the no-attribution license (mit-0) | 18:57 |
| fungi | isc's license is functionally equivalent to 2-clause bsd but was written before berkeley made a 2-clause version | 18:57 |
| *** vhari_ is now known as vhari | 19:39 | |
| opendevreview | Amy Marrich proposed openstack/election master: Update TC Laison https://review.opendev.org/c/openstack/election/+/981040 | 20:53 |
| opendevreview | Merged openstack/openstack-manuals master: Warn crawlers not to touch the tripwire https://review.opendev.org/c/openstack/openstack-manuals/+/978115 | 22:53 |
| cardoe | Sorry folks. The sudden freeze messed up some plumbing and I had to deal with that today which is why I missed the TC. | 23:08 |
| gouthamr | ah sorry to hear that cardoe | 23:34 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!