*** pojadhav|out is now known as pojadhav|ruck | 02:52 | |
*** pojadhav|ruck is now known as pojadhav|brb | 14:28 | |
*** pojadhav|brb is now known as pojadhav|afk | 14:31 | |
opendevreview | Belmiro Moreira proposed openstack/governance master: Release identification and release name https://review.opendev.org/c/openstack/governance/+/829563 | 14:32 |
---|---|---|
opendevreview | Ghanshyam proposed openstack/governance master: Define Zed cycle testing runtime https://review.opendev.org/c/openstack/governance/+/830454 | 14:48 |
gmann | #startmeeting tc | 15:00 |
opendevmeet | Meeting started Thu Feb 24 15:00:07 2022 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
opendevmeet | The meeting name has been set to 'tc' | 15:00 |
gmann | #topic Roll call | 15:00 |
gmann | o/ | 15:00 |
dansmith | o/ | 15:00 |
belmoreira | o/ | 15:00 |
gmann | tc-members: meeting time | 15:00 |
spotz | o/ | 15:00 |
jungleboyj | o/ | 15:00 |
slaweq | o/ | 15:01 |
diablo_rojo | o/ | 15:01 |
gmann | let's start | 15:02 |
gmann | #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 15:02 |
gmann | today agenda ^^ | 15:02 |
gmann | #topic Follow up on past action items | 15:02 |
gmann | no action item from last meeting | 15:02 |
gmann | #toic Gate health check | 15:02 |
yoctozepto | o/ | 15:03 |
gmann | any news on gate/ | 15:03 |
dansmith | not from me, no major concerns that I've seen, | 15:04 |
fungi | just a heads up, we're anticipating losing roughly 30% of our test capacity next month when inap turns off their openstack cloud (they're switching to all vmware apparently) | 15:04 |
dansmith | oof | 15:04 |
jungleboyj | :-( | 15:04 |
fungi | we're looking into some options, but should also degrade gracefully if we have to | 15:04 |
fungi | it's supposedly going to be running until the end of march at least, so there's still some time to find alternatives | 15:05 |
diablo_rojo | Owie | 15:05 |
gmann | humm | 15:05 |
spotz | :( | 15:06 |
fungi | worst case we can probably get some of our existing donors to temporarily up our quotas while we look for new donors to fill the gap | 15:06 |
fungi | timing's not too bad since that'll be right after the yoga release | 15:07 |
gmann | yeah that is good at least | 15:07 |
fungi | and we tend to not overload our available capacity early in the development cycle | 15:07 |
gmann | there are few stable branch gate failure but me too have not noticed any major issue on master gate | 15:07 |
diablo_rojo | Oh thats goodish timing at least. | 15:08 |
gmann | but losing 30% of capacity is big impact even at start of cycle | 15:08 |
spotz | Yeah that's a big chunk of resources | 15:08 |
fungi | yeah, it's not great, but it's why we have a lot of donors and try not to put all of our eggs in one basket, as the addage goes | 15:08 |
gmann | where we need to extend the upgrade testing for skip level thing | 15:08 |
* dmendiza[m] sneaks into the back of the room | 15:09 | |
dansmith | yeah :/ | 15:09 |
fungi | i didn't mean to start a panic, just trying to keep everyone apprised and minimize surprises | 15:09 |
spotz | I appreciate that fungi | 15:10 |
fungi | i'll make sure we keep everyone updated on any developments | 15:10 |
gmann | yeah, let's see how it goes and if no other donner or it impact testing capacity as big then we can discuss. | 15:10 |
jungleboyj | ++ | 15:10 |
gmann | thanks fungi for update. yeah please keep us posted. | 15:10 |
fungi | it's also an opportunity to get some new donors involved ;) | 15:11 |
diablo_rojo | That would be cool :) | 15:11 |
gmann | +1 | 15:11 |
gmann | anything else on gate health? | 15:11 |
dansmith | not from me | 15:11 |
yoctozepto | nope | 15:12 |
gmann | #topic Z cycle Technical Elections | 15:12 |
gmann | there is no election required for PTL as well as for TC | 15:12 |
gmann | we are in process of closing the elections #link https://review.opendev.org/c/openstack/election/+/830544 | 15:12 |
jungleboyj | \o/ | 15:12 |
gmann | once that is merged I will update the results in governance | 15:12 |
gmann | and time we end up with the 17 project with no nomination #link https://etherpad.opendev.org/p/zed-leaderless | 15:13 |
gmann | but most of them are just missed the election notification. which we have to discuss in PTG about how to improve | 15:13 |
jungleboyj | Yeah, that was kind of disappointing. | 15:14 |
gmann | out of 17 we already have 11 projects have late nomination | 15:14 |
gmann | and 6 are still need some leaders | 15:14 |
diablo_rojo | That has been the growing trend, I've noticed. | 15:14 |
jungleboyj | That isn't too bad. | 15:14 |
diablo_rojo | Missing the deadlines. | 15:15 |
diablo_rojo | Nice that so many have piped up already | 15:15 |
gmann | those 6 are Adjutant, Freezer, Murano, Solum, Trove, Watcher | 15:15 |
spotz | Yeah I'm not sure how to fix the communication issue gut glad we olny have 6 left and 1 we already were working on | 15:15 |
gmann | I will check for Trove | 15:16 |
gmann | spotz: yeah | 15:16 |
gmann | let's start adding your opinion and some stats in etherpad and based on those we can discuss in next meeting or so | 15:16 |
gmann | I will put stats next week once feature freeze is done | 15:17 |
gmann | and once we close the election and also put these on ML | 15:17 |
gmann | anything else on election thing? | 15:17 |
gmann | #topic PTG Preparation | 15:18 |
gmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html | 15:18 |
gmann | ^^ sent email about PTG planning | 15:18 |
gmann | #link https://etherpad.opendev.org/p/tc-zed-ptg | 15:18 |
gmann | ^^ etherpad to collect the topic, feel free to keep adding any topic you think we need to disucss | 15:19 |
gmann | jungleboyj: can you plese add user survey which we need to cover in PTG? | 15:19 |
jungleboyj | Yes. Will work on that. | 15:20 |
gmann | thanks | 15:20 |
gmann | and to book slot before 11th Mar, I have created the doodle vote for checking the timing. #link https://doodle.com/poll/gz4dy67vmew5wmn9 | 15:21 |
gmann | please add your availability on this | 15:21 |
spotz | Not sure I hit submit yet, D&I WG already has a slot on Monday so may need to adjust things | 15:22 |
belmoreira | shouldn't we wait for the new TC members? for the availability | 15:22 |
gmann | belmoreira: yeah, good point. it is open for all members including new or community members too | 15:22 |
gmann | I will make sure we will not close it until we have new members onboard in TC | 15:23 |
jungleboyj | Assuming that Cinder will be mornings of Tue-Fri, but will prioritize TC meetings. | 15:23 |
gmann | and like we had TC+ Community leaders sessions in last PTG, we will continue that #link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027382.html | 15:24 |
gmann | there is doodle poll for that too #link https://doodle.com/poll/dcer6i3wk2b8eim3 | 15:24 |
diablo_rojo | spotz, if you remind me post meeting I can check for you | 15:24 |
gmann | please add your availability | 15:24 |
spotz | diablo_rojo: On gmann's doodle? I know I did the ethercalc | 15:25 |
gmann | spotz: I think no, i cannot see that. | 15:25 |
diablo_rojo | spotz, oh I thought you were talking about for the D&I working group signup survey | 15:25 |
diablo_rojo | My bad | 15:25 |
diablo_rojo | Misread :) | 15:26 |
gmann | that is all from me on PTG, just want to give headsup and will continue it in next meeting or until we have new members | 15:26 |
gmann | anything else from anyone on PTG or slot wise? | 15:26 |
gmann | #topic Dropping tags framework - next steps (yoctozepto) | 15:27 |
gmann | yoctozepto: please go ahead on updates | 15:28 |
yoctozepto | patches to release repo are proposed and pending to merge | 15:28 |
yoctozepto | fungi has proposed the vmt patch | 15:28 |
yoctozepto | also pending | 15:28 |
diablo_rojo | Should I start outreach with the k8s folks? | 15:28 |
gmann | yeah, #link https://review.opendev.org/c/openstack/releases/+/829014 #link https://review.opendev.org/c/openstack/releases/+/830084/2 | 15:28 |
gmann | elodilles: ^^ | 15:28 |
yoctozepto | we are waiting for website folks to confirm their removal | 15:28 |
gmann | #link https://review.opendev.org/c/openstack/governance/+/830478 | 15:29 |
fungi | yeah, there's an "urgent" ticket open with tipit (the webdev contracting company the foundation uses) to remove the "project details" sections from pages like https://www.openstack.org/software/releases/xena/components/nova so that we won't end up with broken links there when the tag pages disappear | 15:29 |
fungi | i have a feeling it will be done by the end of the week (maybe even later today) but i'll let you know once it's clear | 15:29 |
yoctozepto | thanks | 15:30 |
gmann | thanks for handling that | 15:30 |
yoctozepto | the ossa dep has merged | 15:30 |
gmann | yeah | 15:30 |
yoctozepto | yes, thank you fungi for helping! | 15:30 |
gmann | so other that those we have two more remaining tags are 1. assert_follows-standard-deprecation 2. stable_follows-policy | 15:30 |
yoctozepto | so their content goes to project team guide | 15:31 |
yoctozepto | if it's missing there | 15:31 |
gmann | yoctozepto: if I remember we need to move these (their documentation) to project-team-guide or some place right? | 15:31 |
gmann | ok | 15:31 |
yoctozepto | I have yet to do this | 15:31 |
yoctozepto | yeah | 15:31 |
gmann | I can help on those next week. | 15:31 |
gmann | sure, I will review them | 15:31 |
yoctozepto | ok, thanks, much appreciated | 15:31 |
gmann | then | 15:31 |
gmann | thanks yoctozepto for working on those, anything else on this? | 15:32 |
gmann | #topic "Artificially inflated requirements in os-brick" (rosmaita) | 15:33 |
yoctozepto | not from my side | 15:33 |
gmann | k | 15:33 |
gmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027343.html | 15:33 |
gmann | #link https://review.opendev.org/c/openstack/os-brick/+/828802 | 15:33 |
gmann | rosmaita: your turn | 15:33 |
rosmaita | hello | 15:33 |
dansmith | tbh, I had a hard time understanding the concern | 15:33 |
rosmaita | i want to ask about this because i am about to artificially inflate the cinderclient requirements | 15:33 |
rosmaita | well, i think it's a packager/deployer consideration | 15:34 |
rosmaita | my question right now is does the TC feel I need to worry about this? | 15:34 |
yoctozepto | I think we have a general issue with handling the deps constraints | 15:34 |
yoctozepto | and these are just various blurps that we get | 15:34 |
dansmith | yoctozepto: haven't we always? | 15:35 |
yoctozepto | dansmith: yes, it's using present tense because it's still the case :D | 15:35 |
dansmith | ack :) | 15:35 |
fungi | it raises the question why we bother to list versions in requirements files at all if we only really care that tests pass with our constraints list | 15:35 |
dansmith | so part of the concern here is keeping deps old enough that they work on less than the most current OS versions while also moving them forward right? | 15:35 |
gmann | rosmaita: and it is for consistency not like we have to bump due to incompatibility for cinder, python-cinderclient Yoga version | 15:35 |
rosmaita | well, it's two things | 15:36 |
dansmith | fungi: version ranges you mean right? | 15:36 |
fungi | dansmith: even that they work with "current" os versions, rather than whatever just got published to pypi yesterday | 15:36 |
yoctozepto | well, bumping regularly makes sense; though bumping to always-latest might not be | 15:36 |
rosmaita | first is that i don't like listing minima that we haven't been testing with | 15:36 |
dansmith | fungi: sure, sure | 15:36 |
rosmaita | second is that i like to keep the requirements consistent across all the cinder project deliverables | 15:36 |
gmann | so that is about testing lower constraints right | 15:37 |
yoctozepto | gmann: +/- | 15:37 |
yoctozepto | lower-constraints were not really tested well | 15:37 |
dansmith | rosmaita: tbh, having brick's requirements not exactly equal to nova-compute is also as important as cinder/brick right? | 15:37 |
gmann | yoctozepto: yeah. which is always the case | 15:37 |
yoctozepto | my issue is | 15:37 |
yoctozepto | if we are going to get 30% hit on gating capacity | 15:38 |
gmann | min vesions listed in req file is always not known that they work or not | 15:38 |
rosmaita | dansmith: i think it mostly affects nova's lower-constraints job | 15:38 |
yoctozepto | we can't really say let's run devstack job alternatives with l-c | 15:38 |
yoctozepto | also, l-c differ between projects | 15:38 |
fungi | right, the friction is that there's no concrete way to manitain lists of lower bounds for dependencies in a way we can reliably test, but people want to be able to install our software without having to also update every last dependency even when those updates may contain only unrelated changes | 15:38 |
yoctozepto | so with our coinstallability requirement | 15:38 |
yoctozepto | we cannot do this | 15:38 |
gmann | true | 15:38 |
dansmith | rosmaita: I mean in reality.. people have to be able to install nova-compute and brick in the same environment, so they have to have a consistent set of reqs that work together | 15:38 |
yoctozepto | (I don't like this requirement and think it's wrong nowadays but I understand people got used to it) | 15:38 |
gmann | main question is "what we want to convey with requirements.txt file" ? | 15:39 |
yoctozepto | and yeah, cases like dansmith mentioned | 15:39 |
rosmaita | gmann: ++ | 15:39 |
yoctozepto | where openstack controls both the caller and the callee | 15:39 |
jungleboyj | gmann: ++ | 15:39 |
yoctozepto | gmann: ++ | 15:39 |
yoctozepto | what we want and what we can, basically | 15:39 |
fungi | the "cases" dansmith mentioned aren't a few isolated places we have to worry about coinstallability, they're representative of a large number of such interdeopendencies which need different projects installed together into the same environment | 15:40 |
gmann | and having them inconsistent make then more wrost, like one case dansmith mentioned | 15:40 |
dansmith | well, with containers those pieces are smaller than all of openstack, which is the case for conventional packages | 15:40 |
yoctozepto | precisely | 15:40 |
dansmith | but, things like brick tie certain pieces together which would otherwise be separate | 15:40 |
dansmith | i.e. cinder and nova, linked through brick | 15:41 |
gmann | I feel it at least (where we cannot test all the cases), making minima consistent with adjacent/used lib make sense | 15:41 |
fungi | also i can't see us telling "traditional distros" to take a hike and stop bothering trying to package openstack | 15:41 |
dansmith | so, what if we tie our maximum to pip or whatever we need, and tie our minimum to ubuntu LTS or LTS-1 ? | 15:41 |
dansmith | meaning 18.04 right now, soon to be 20.04 | 15:42 |
gmann | dansmith: you mean for per repo or for all openstack ? | 15:42 |
dansmith | for lower-constraints, effectively | 15:42 |
dansmith | I'm just thinking that maybe the skip-level job would give us testing at that older level, while also testing what a lot of people would actually be doing in terms of upgrades | 15:42 |
gmann | but that does not solve the current question from rosmaita. making few adjacent/related lib minima consistent ? | 15:43 |
fungi | that seems on its face like it could be a reasonable compromise, but you'd actually need to test with those packages not what's on pypi, because the distros manually make those things coinstallable even when the python packages may say they can't be (they backport fixes and so on to old base versions) | 15:43 |
dansmith | well, part of his concern, I think, is that the minima aren't tested | 15:43 |
dansmith | fungi: right | 15:43 |
fungi | so we can't `pip install` the collective set of versions of our dependencies which are listed by those distros | 15:43 |
dansmith | fungi: I guess we might need a delta of things that aren't shipped, but we'd need to know the precise formula of that delta and no more | 15:43 |
fungi | i do think it's reasonable to say that we simply lack the available resources to think about whether we need to update our dependencies, that distros should ignore the lower bounds they find in our python packages and test things themselves separately. i mean, it's more or less the position os-brick has taken, it's just not been stated clearly to the community | 15:45 |
dansmith | yup | 15:46 |
rosmaita | that sounds good to me | 15:46 |
yoctozepto | fungi: ++ | 15:46 |
yoctozepto | that's reasonable | 15:46 |
gmann | yeah, we should cleanup l-c completely to make it clear | 15:46 |
dansmith | gmann: wouldn't that be nice :) | 15:47 |
fungi | we don't (and in my opinion realistically can't) manage and test minimum versions, as great as that would be. i tried to explain on the ml whythe concept is fundamentally flawed | 15:47 |
yoctozepto | and cleanup ranges in requirements.txt gmann | 15:47 |
gmann | yoctozepto: yeah inclduing that | 15:47 |
yoctozepto | I'm all in | 15:47 |
yoctozepto | that's a clear message | 15:47 |
yoctozepto | plus a resolution | 15:47 |
dansmith | so we have no l-c or u-c, just reqs.txt? | 15:47 |
yoctozepto | and we close this chapter | 15:47 |
yoctozepto | dansmith: just reqs and u-c picking tested versions | 15:47 |
rosmaita | i think we still need u-c | 15:47 |
fungi | i think we still need the upper constraints becaus ethat's how we pin our testing environments | 15:48 |
gmann | I will add this to PTG to discuss it more and find some clear way instead of current mixed one. | 15:48 |
rosmaita | fungi: ++ | 15:48 |
dansmith | I don't see why we need both | 15:48 |
fungi | yes, it needs much more discussion with a broader cross-section of the community | 15:48 |
gmann | yeah if l-c goes then we do not need both | 15:48 |
yoctozepto | dansmith: we need upper boundary for testing coinstallability | 15:48 |
yoctozepto | reqs specify which of those are used by a project | 15:48 |
dansmith | yoctozepto: we don't if we're not promising*any* ranges | 15:48 |
fungi | dansmith: i think we can drop version numbers from requirements.txt in projects, probably, but that too will need some experimenting | 15:49 |
dansmith | yoctozepto: we could just have g-r, which is effectively u-c today as our requirements I think | 15:49 |
gmann | #action gmann to add topic "lower bound versions direction as community" in PTG | 15:49 |
yoctozepto | dansmith: ugh, no idea how well g-r behaves nowadays | 15:49 |
yoctozepto | I think it's not used in many places | 15:49 |
yoctozepto | anyway, something to experiment with | 15:49 |
dansmith | I think we're mincing words, but yeah | 15:50 |
fungi | i can exlpain the current state of global requirements management in detail, but not within the time remaining for this meeting | 15:50 |
spotz | rosmaita: Is this something you need decided on before PTG or are you good with gmann's action item? | 15:50 |
rosmaita | i am ok with ptg discussion, especially since | 15:50 |
rosmaita | it appears everyone is OK with what i did with os-brick | 15:51 |
jungleboyj | ++ | 15:51 |
rosmaita | and plan to do with cinderclient and cinder | 15:51 |
gmann | rosmaita: anything blocking until we discuss in PTG? | 15:51 |
spotz | ++ | 15:51 |
rosmaita | no, i just wanted to get a sense of whether this issue was considered a problem by the general community | 15:51 |
gmann | rosmaita: yeah os-bricks way seems fine but I will say to do for cinder or client, let's wait for PTG outcome? | 15:51 |
gmann | yeah it is surly an open confusion for long. | 15:52 |
rosmaita | i guess i could leave those alone | 15:52 |
rosmaita | except for oslo.vmware | 15:53 |
gmann | ok | 15:53 |
gmann | anything else? | 15:53 |
rosmaita | ok, i will be less aggressive with the requirements for cinderclient and cinder | 15:53 |
rosmaita | no, that's all from me | 15:53 |
rosmaita | thanks everyone | 15:54 |
gmann | rosmaita: thanks for brining it, let's see if we can find some permanent solution this time | 15:54 |
gmann | #topic Open Reviews | 15:54 |
gmann | #link https://review.opendev.org/q/projects:openstack/governance+is:open | 15:54 |
gmann | open reviews | 15:54 |
dansmith | gmann: should I be rollcall vote'ing on my own resolution? | 15:54 |
gmann | dansmith: yes, you can | 15:55 |
gmann | dansmith: I saw one question there. | 15:55 |
dansmith | okay so we're at 4 +1s there and several +1s from the community.. | 15:55 |
dansmith | yep, -1 from zigo, although I don't really understand.. he'd be +1 if we ticked and tocked more, but not just this amount :) | 15:56 |
gmann | yeah, you replied, i did not see | 15:56 |
yoctozepto | well, zigo raised the just-discussed issue as well so | 15:56 |
gmann | number of votes are good, we just need to wait for 3 more days as per formal-vote process | 15:56 |
dansmith | okay, that was my next question, thanks :) | 15:56 |
belmoreira | we also discuss it in the previous video meeting for this topic | 15:57 |
gmann | yeah | 15:57 |
belmoreira | this is an important change. It would be great to have all the TC represented in the change | 15:57 |
* jungleboyj has a tab open | 15:58 | |
* yoctozepto has a tab open too | 15:58 | |
* yoctozepto expects a RV+1 tbh | 15:58 | |
gmann | it is mergeable on 28th, I will do | 15:58 |
* spotz has lots of tabs | 15:59 | |
gmann | yeah, the current TC votes as per on 28th | 15:59 |
dansmith | we should also get belmoreira's as soon as it's allowed, before he disappears, IMHO | 15:59 |
dansmith | I mean.. "disappears" :) | 15:59 |
yoctozepto | yeah, I was about to ask | 15:59 |
yoctozepto | if you plan a kidnapping | 15:59 |
dansmith | yoctozepto: too soon | 15:59 |
yoctozepto | yeah | 15:59 |
dansmith | :P | 15:59 |
belmoreira | :) | 15:59 |
gmann | :) | 15:59 |
gmann | other thing i pushed zed testing runtime #link https://review.opendev.org/c/openstack/governance/+/830454 | 15:59 |
gmann | keeping ubuntu20.04 as 22.04 is planned to release on 21st April which is after Zed cycle start | 16:00 |
gmann | any concern on that? | 16:00 |
yoctozepto | no, we can update later | 16:00 |
dansmith | I need to re-+1 both of those | 16:00 |
yoctozepto | well, "you" can :D | 16:00 |
gmann | yoctozepto: humm, I am thinking not to do. | 16:00 |
gmann | and consider in AA ? | 16:00 |
spotz | Are we tested on it? | 16:01 |
yoctozepto | gmann: we/you can query the community | 16:01 |
dansmith | yeah, IMHO, we should not shift the Z reqs late and just call this good | 16:01 |
yoctozepto | and, well | 16:01 |
gmann | spotz: on 22.04 ? | 16:01 |
yoctozepto | if QA can handle this | 16:01 |
gmann | dansmith: yeah | 16:01 |
yoctozepto | I would stay on 20.04 too | 16:01 |
gmann | yoctozepto: I do not think so, I am doing mostly the migration for last few times and it involve lot of testing | 16:02 |
yoctozepto | gmann: yeah, I know the drill | 16:02 |
spotz | gmann: teah | 16:02 |
yoctozepto | and can't help nowadays | 16:02 |
gmann | spotz: that is not yet, as not released officially | 16:02 |
yoctozepto | so let's not ruin Zed because of this | 16:02 |
yoctozepto | we're past time | 16:03 |
gmann | yeah, lot of other things also we need to finish like RBAC etc | 16:03 |
yoctozepto | OH NO | 16:03 |
gmann | anyways we are out of time, please review and add you vote there | 16:03 |
yoctozepto | thanks gmann | 16:03 |
yoctozepto | take care | 16:03 |
jungleboyj | gmann: Thanks! | 16:03 |
gmann | that is all for today, next meeting will be video call. I will add link there | 16:04 |
gmann | thanks all for joining | 16:04 |
gmann | #endmeeting | 16:04 |
opendevmeet | Meeting ended Thu Feb 24 16:04:10 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:04 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-24-15.00.html | 16:04 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-24-15.00.txt | 16:04 |
opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-24-15.00.log.html | 16:04 |
spotz | Thanks gmann and everyone! | 16:04 |
diablo_rojo | Thanks gmann! | 16:04 |
*** pojadhav|afk is now known as pojadhav|out | 16:25 | |
*** ykarel is now known as ykarel|away | 16:31 | |
opendevreview | Merged openstack/election master: Close out Zed elections https://review.opendev.org/c/openstack/election/+/830544 | 22:06 |
opendevreview | Ghanshyam proposed openstack/governance master: Close Zed PTL Elections https://review.opendev.org/c/openstack/governance/+/830910 | 22:38 |
opendevreview | Ghanshyam proposed openstack/governance master: Close TC Zed election https://review.opendev.org/c/openstack/governance/+/830915 | 23:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!