| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Add 2026.1 TC Chair directory https://review.opendev.org/c/openstack/governance/+/962048 | 05:06 |
|---|---|---|
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Add gouthamr's nomination for 2026.1 TC chair https://review.opendev.org/c/openstack/governance/+/962049 | 05:06 |
| opendevreview | Merged openstack/governance master: Add 2026.1 TC Chair directory https://review.opendev.org/c/openstack/governance/+/962048 | 05:30 |
| *** ralonsoh_ is now known as ralonsoh | 07:33 | |
| opendevreview | Omer Schwartz proposed openstack/governance master: Add TC/PTL results from 2026.1 election https://review.opendev.org/c/openstack/governance/+/961598 | 07:52 |
| *** jroll01 is now known as jroll0 | 08:29 | |
| *** sean-k-mooney is now known as sean-k-mooney-pto | 14:51 | |
| gouthamr | tc-members: a gentle reminder that this week's IRC meeting will happen here in ~1 hour | 16:00 |
| gouthamr | the agenda is here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 16:00 |
| bauzas | gouthamr: and unfortunately a gentle reminder that I can't be again attending on this meeting, apologies :( | 16:01 |
| gouthamr | ack bauzas | 16:01 |
| gouthamr | we'll discuss the new timing too! | 16:01 |
| gouthamr | ty for filling out your preferences, like you all noticed though - it'll be tough to align to a single slot | 16:03 |
| bauzas | gouthamr: about that (before I leave), I'm fine with alternate times if that helps | 16:55 |
| bauzas | I'm also fine with late european times, as I wrote, if that helps finding a quorum | 16:56 |
| bauzas | (just expressing my opinions before I leave) | 16:56 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Sep 23 17:00:45 2025 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 |
| gtema | o/ | 17:01 |
| tonyb | o/ | 17:01 |
| noonedeadpunk | o/ | 17:02 |
| frickler | \o | 17:02 |
| * gouthamr passes some strong coffee to tonyb | 17:02 | |
| gouthamr | courtesy-ping: spotz[m], cardoe, mnasiadka | 17:03 |
| mnasiadka | O/ | 17:03 |
| cardoe | I’m on | 17:03 |
| gouthamr | ^ i refreshed the ping list, please do edit it on the wiki if you want to be alerted | 17:03 |
| cardoe | Kinda. Gimme 3 minutes. | 17:03 |
| gouthamr | noted absence: b a u z a s | 17:04 |
| tonyb | cute | 17:04 |
| gouthamr | alright, lets get started.. | 17:06 |
| gouthamr | first off, congratulations on your (re)election to the TC, cardoe frickler ba u zas and tonyb | 17:06 |
| gouthamr | and lets take a moment to acknowledge the long hours of work its taken to run the elections - ianychoi and slaweq did a great job as always, and continued to make the process better by adopting feedback expeditiously | 17:07 |
| cardoe | agreed. cheers folks on another job well done. | 17:08 |
| gouthamr | also as gmaan_pto takes a well needed break, i do hope he'll still join us in these meetings when he's back! | 17:08 |
| * tonyb applauds | 17:09 | |
| gouthamr | there's a governance patch formalizing these changes: | 17:09 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/961598 (Add TC/PTL results from 2026.1 election) | 17:09 |
| gouthamr | but that needs https://review.opendev.org/c/openstack/election/+/961596 | 17:10 |
| gouthamr | ^ slaweq ianychoi if you'd like to merge that elections repo change and make further changes, i don't mind | 17:10 |
| gouthamr | frickler: ^ if you're okay with creating another patch to fix the nick.. | 17:11 |
| gouthamr | several IRC nick fixes need to be done, but unless they can be done super quick, lets avoid them | 17:11 |
| cardoe | Looks like a few more manual updates needed before we can approve. | 17:12 |
| gouthamr | doc updates are trivial, wanted to merge these and formalize the results though since it concludes the election process | 17:13 |
| gouthamr | #topic Last Week's AIs | 17:13 |
| gouthamr | we took a note to check on the electorate, crunching numbers and share feedback on openstack-discuss: | 17:14 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CMBMBPWDCQHFSCYGUWMBZHVOB2K7EILB/ | 17:14 |
| gouthamr | we can follow up on this thread, and make any recommendations and follow up.. i'll bump this topic to next week | 17:15 |
| gouthamr | next up: status check on the "leaderless" projects | 17:16 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/G4FSLQDGJBRY6G4JQ3SSIPN2UVX7BC4K/ (Venus) | 17:16 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/22GL7TB54WY4T2JDEVKFQCEKQY4AAVAN/ (Vitrage) | 17:16 |
| spotz[m] | o/ | 17:16 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/WR277VO5VNJP2Z5WPZ7RPWRSW2Y7F7CT/ (OpenStack Charms) | 17:16 |
| gouthamr | freyes_ responded on the last thread here.. we need an appointment patch to be raised on openstack/governance | 17:17 |
| gouthamr | and i was hoping to get some clarity on the state of the Charms project - i.e., is it actively maintained, how does one approach the maintainers | 17:17 |
| fungi | they have a ton of repos too, would be great if the new ptl looked into retiring any that are no longer needed/maintained | 17:19 |
| gouthamr | ah true | 17:19 |
| gouthamr | regarding Venus: i was planning to run the project_stats tool to share some insights, but, a peek on gerrit tells me: | 17:20 |
| gouthamr | - there was little to no activity on the repos in the 2025.2 cycle | 17:20 |
| gouthamr | - the release team identified that CI is broken on the "openstack/venus" repo | 17:20 |
| gouthamr | #link https://review.opendev.org/q/topic:release-health-check-flamingo+is:open | 17:20 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CVWXC6RRTBWRDNQR2TTMT6FN4ZNUVJHH/#57BOQXZ563BAJOLGHYWURRQNDEORKILA | 17:20 |
| opendevreview | Felipe Reyes proposed openstack/governance master: Appoint Felipe Reyes as PTL for OpenStack Charms https://review.opendev.org/c/openstack/governance/+/962121 | 17:20 |
| gouthamr | freyes_++ | 17:21 |
| freyes_ | gouthamr, ^ , does this look ok? | 17:21 |
| gouthamr | freyes_: it does, ty.. do you mind watching comments on that change and responding to them.. | 17:22 |
| gouthamr | freyes_: we have a bunch of questions on Charms that we need some clarity on - might be tangentially related to the PTL appointment itself | 17:23 |
| freyes_ | gouthamr, ack, I'm into back-to-back meeting for the next few hours, but will circle back before going offline today | 17:23 |
| gouthamr | freyes_: great, ty | 17:24 |
| freyes_ | np, thanks to you | 17:24 |
| gouthamr | regarding venus, we can discuss the status thoroughly next week once we have the project-stats o/p.. | 17:24 |
| gouthamr | we're waiting on vitrage in the same manner - but this one has had maintenance activity on gerrit | 17:25 |
| gouthamr | and noonedeadpunk had been shepherding it until recently | 17:25 |
| gouthamr | short of saying "you're it again" noonedeadpunk, i'm unsure about the implications here.. the core-team is huge | 17:26 |
| gouthamr | but some email addresses are no longer active | 17:27 |
| fungi | to new ptl: please pare that list down to active participants | 17:27 |
| mnasiadka | gouthamr: majority of the Gerrit core group is my former team in Nokia/Cloudband, it seems it hasn’t been cleaned up in a very long time | 17:28 |
| noonedeadpunk | yeah, it was not | 17:28 |
| noonedeadpunk | I didn't do that so far :( | 17:28 |
| noonedeadpunk | Um, I still didn't get time to check on vitrage tempest, which I planned for the past week | 17:29 |
| noonedeadpunk | and I was thinking to myself that on solving tempest would depend if I'd be able to step again into these shoes again or not | 17:29 |
| gouthamr | yes, is this a project that's surviving on your goodwill/availability? or is this useful to form a community around? | 17:30 |
| gouthamr | maybe these are tough questions and we can take some time to tackle this - feel free though to share the situation on the ML | 17:31 |
| gouthamr | if there are users out there, they may be under the assumption that we've got the situation handled | 17:31 |
| gouthamr | i think the next AI can be marked complete too: | 17:34 |
| gouthamr | vendoring the ply library into yaql with the TC's approval: | 17:34 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PKWNZ7QL6PRJI2WXMMWYYZYWYZA3Z7E4/#PKWNZ7QL6PRJI2WXMMWYYZYWYZA3Z7E4 | 17:34 |
| gouthamr | #link https://review.opendev.org/c/openstack/yaql/+/961398 | 17:34 |
| noonedeadpunk | well, I think that it's really important especially for newcomers to ecosystem to build awareness about operational principles | 17:34 |
| noonedeadpunk | and can show a way on how to debug issues when they arise | 17:34 |
| gouthamr | ah! | 17:34 |
| gouthamr | i hadn't thought of that use case | 17:34 |
| noonedeadpunk | but like... I was not able to convince to add to our production even... | 17:34 |
| gouthamr | ack, if there's a worthwhile improvement to be made to make things more attractive/usable, i would suggest working with diablo_rojo_phone to identify student interns | 17:36 |
| gouthamr | or even outreachy | 17:36 |
| gouthamr | although it'll need more of your already limited time to coach contributors | 17:36 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PBQSHMZIYXHKA7OD756OAJS4OZOHMGWK/ | 17:37 |
| gouthamr | ^ silent plug for outreachy | 17:37 |
| gouthamr | (it looks like we have funding \o/ - it'd be nice to have mentor/s and an intern to continue this engagement!) | 17:37 |
| spotz[m] | we have funding for one intern for the December cohort | 17:38 |
| fungi | i'll note that zigo raised concern over the idea of copying ply into yaql from a package maintainer perspective, vs maintaining it as a stand-alone python library. i haven't looked to see what the reverse-dependencies of python3-ply in debian might be (besides python3-yaql obviously) | 17:38 |
| noonedeadpunk | I'd reather put that towards freezer tbh, as way more important project.... | 17:38 |
| spotz[m] | We were lucky enough to get funding for 1 intern each cohort this year. Using the spot justifies for next year | 17:39 |
| gouthamr | ++ | 17:39 |
| zigo | fungi: Answer is: A LOT. https://paste.opendev.org/show/bJa1wpmbbTlrRFNSucOD/ | 17:39 |
| diablo_rojo_phone | I will definitely have universities looking for project proposals November/ decemberish. | 17:39 |
| zigo | Which is why I see no point embedding ... | 17:39 |
| diablo_rojo_phone | We just missed the current semester by a month or so. | 17:39 |
| zigo | Someone will for sure fork or take over maintainership. | 17:39 |
| clarkb | it seems like the current maintainer doesn't want to stop maintaining it. They just don't want to deal with python packaging so a fork seems more likely if it goes that route | 17:40 |
| fungi | zigo: thanks, that's more than i expected | 17:40 |
| clarkb | that said its small and self contained and it doesn't do network connectivity. Its like the perfect thing to vendor... | 17:40 |
| fungi | yeah, but if every project that uses ply vendors its own copy, they will become out-of-sync near-duplicates that all need to be patched the next time there's a security vulnerability discovered in it | 17:41 |
| fungi | at least that's the typical concern raised at the distribution level | 17:42 |
| fungi | so the distro is going to strip out yaql's copy of ply and try to patch in a shared copy that only needs to get fixed in one place for all the projects that need it | 17:43 |
| gouthamr | vendored code is now project code no? i mean, we'll be in line to maintain/patch it for the future.. so vulnerabity scanning tools for instance will have to see the changes in the yaql library | 17:43 |
| gouthamr | fungi: i hope not, because theoretically, we could alter it's behavior now and make it incompatible with ply | 17:44 |
| fungi | yes, that's the bigger risk. but basically the distro would prefer to patch the python3-ply package rather than patching the same vulnerability in 25 separate packages that vendor slightly divergent copies of it | 17:45 |
| gouthamr | understood | 17:45 |
| clarkb | one option may be to do something like build a python package repo for it and auto update ply via a git submodule or something | 17:46 |
| clarkb | it may be worth talking to the maintainer to see if tehy would be interested in someone else doing that work | 17:46 |
| fungi | (this is also why it's almost impossible to package a lot of typical javascript projects, because they all like to rely on internal copies of different versions of dependencies) | 17:47 |
| gouthamr | there's a meme for that | 17:49 |
| cardoe | So losing what we want to do with this one? | 17:49 |
| gouthamr | we're considering the implications to distros, and actively taking notes on the next situation.. i don't think we'd change the situation with openstack/yaql | 17:50 |
| fungi | i would just make absolutely certain there's not some way to have ply as a separate dependency before deciding to copy it into yaql, since this choice is an added burden for downstream package maintainers and needs to be recognized as such | 17:51 |
| mnasiadka | If the author is not interested just in packaging (and new features) can we just reference it using git+https instead of pypi? | 17:52 |
| fungi | and yaql is apparently one of 25 projects packaged in debian that share this dependency, so we should avoid making decisions in a vacuum | 17:52 |
| clarkb | mnasiadka: that only works if there is packaging toolin in the repo | 17:53 |
| clarkb | (which does exist for now) | 17:53 |
| frickler | well https://review.opendev.org/c/openstack/yaql/+/961398 was merged, do you want to revert this? not sure who actually maintains yaql | 17:55 |
| fungi | if it turns out that the ply maintainer doesn't share concerns about reusability and the impact on downstream consumers and packagers, then migrating to or maintaining an alternative solution could be on the table too | 17:55 |
| gouthamr | by vendoring that code, we've created that alternative solution | 17:55 |
| fungi | we've solved it for yaql, but not the other 24 projects that use it | 17:56 |
| fungi | and if they all "solve" this the same way, it's problematic | 17:56 |
| gouthamr | for sure.. | 17:56 |
| clarkb | you could actually just have a zuul job publish the library to pypi under a different name as long as the repo contains packaging tooling in it | 17:56 |
| gouthamr | as a service we could offer to the ply maintainer? but then, we need someone to do it for perpetuity, no? | 17:57 |
| gouthamr | not against it, just wanted to see how that would work with our community | 17:57 |
| gouthamr | our "deliverables" are maintained by project teams and SIGs | 17:57 |
| clarkb | I was thinking you'd do it without their involvement as tehy aer interestd in releases and publishing packages | 17:57 |
| fungi | just noting there are other projects i'm involved in that also appear on the list of ply's reverse-dependencies, so those will eventually need to take action as well if ply stops providing packaging | 17:58 |
| mnasiadka | Well, gertty is also on the list, so we’ll at least host two ,,versions’’ of ply in OpenDev it seems | 17:58 |
| tonyb | I like the git submodule approach, that seems like a reasonable balance. | 17:58 |
| tonyb | I think we can leave https://review.opendev.org/c/openstack/yaql/+/961398 in place for now | 17:59 |
| clarkb | it seems like they don't want to manage the overhead of deciding when relaeses should be made and publishing them as packages | 17:59 |
| clarkb | so if not forking entirely filling that void is probably where you can be most helpful | 17:59 |
| fungi | so not just packaging but also releasing | 17:59 |
| tonyb | and give me an AI to talk the ply maintainer about their willingness to work with that (or some other route) and bring that back | 18:00 |
| frickler | so ... lots of options of what might be done ... but is there any volunteer to actually do anything about this? | 18:00 |
| gouthamr | sounds like one on tonyb :) | 18:00 |
| tonyb | with more information from the maintainer and possibly the other ply users we may have a better answer | 18:01 |
| * gouthamr we're over the hour | 18:01 | |
| gouthamr | cardoe: would you like to chat about the skyline topic after the meeting? | 18:01 |
| cardoe | Sure | 18:02 |
| gouthamr | or is it okay to wait until next week? | 18:02 |
| fungi | but also if we do choose to just stick with the current solution in yaql, we can acknowledge that it was the easy way out and that we understand it wasn't optimal for downstream distributions | 18:02 |
| cardoe | I mean I'd just like to see skyline work. | 18:02 |
| cardoe | The CI has been busted for a while. I'm not even sure how the last patches were merged in because the issue is that the Zuul config is wrong. | 18:02 |
| fungi | skyline has this exact problem, but magnified tenfold (thanks javascript!) | 18:02 |
| gouthamr | cardoe: think it'll be nice to have everyone here for that topic, so i can push it to next week | 18:03 |
| gouthamr | we're past the RC deadline, so hopefully the patches you're chasing can wait? | 18:03 |
| gouthamr | or are they release blockers?' | 18:03 |
| clarkb | cardoe: the issue is related to the ansible 11 by default update in zuul itself | 18:04 |
| clarkb | cardoe: so presumably the last change that merged did so before the zuul default updated within opendev | 18:04 |
| cardoe | ah well that makes sense | 18:04 |
| cardoe | gouthamr: well the 2025.2 release commits fail from that. | 18:04 |
| fungi | the skyline maintainers sent a list of release highlights to the foundation's china community manager because they didn't know the process for adding them to the upstream release repo list. i've tried to communicate some of these concerns back through the same channel | 18:04 |
| gouthamr | :( | 18:04 |
| tonyb | re ply the author has stated "If you use PLY, you should copy it into your project." but they may accept a middle ground | 18:04 |
| gouthamr | fungi: the team needs to extend to actually sustain this useful project.. think cardoe's interest in this is great! | 18:06 |
| gouthamr | alright we're 6 minutes over | 18:06 |
| fungi | yes, i tried to pass that along to them | 18:06 |
| gouthamr | i'll wrap this up, sorry we didn't get through a lot today.. please don't let this wrap up stop any time critical discussion | 18:06 |
| gouthamr | thank you all for joining | 18:07 |
| gouthamr | #endmeeting | 18:07 |
| opendevmeet | Meeting ended Tue Sep 23 18:07:06 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:07 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-23-17.00.html | 18:07 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-23-17.00.txt | 18:07 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-23-17.00.log.html | 18:07 |
| gouthamr | tc-members: i had a time critical discussion, were there any nominations for tc chair? i'd like to know by EOD today please | 18:07 |
| gouthamr | also need one or more of you to ack this change: https://review.opendev.org/c/openstack/governance/+/962049 | 18:09 |
| gouthamr | i don't mind doing this for another term.. but, would definitely be okay handing this off right away too, and help! | 18:09 |
| clarkb | cardoe: I think you need to squash https://review.opendev.org/c/openstack/skyline-apiserver/+/961562 and https://review.opendev.org/c/openstack/skyline-apiserver/+/961595 together or make one of the jobs non voting in the change that fixes the other then flip it back when you fix the nonvoting job | 18:10 |
| clarkb | of course non of that matters if no one is reviewing things, but maybe part of the problem there is that neither of those changes are in a mergable state | 18:10 |
| cardoe | clarkb: yeah there's some squashing and what not that needs to happen. | 18:10 |
| clarkb | I could see someone saying it isn't worth reviewing if they can't merge things anyway | 18:11 |
| clarkb | so step 0 might be addressing that to remove any excuses | 18:11 |
| cardoe | https://review.opendev.org/c/openstack/skyline-console/+/961092 | 18:11 |
| cardoe | That's the basic one to start things to pass for example. | 18:12 |
| clarkb | ah ok so there is a passing change in the other repo that fixes similar issues | 18:12 |
| cardoe | But getting 0 traction | 18:12 |
| cardoe | I sent the email to the ML with data but essentially the only stuff that gets merged/reviewed are patches by the 3 cores who are all from the same company. | 18:12 |
| clarkb | right I just wanted to call out that not reviewing something that doesn't pass testing is not itself typically indicative of a problem. | 18:13 |
| fungi | cardoe: these are things i raised to horace yesterday, i'm hoping that they just don't realize there are people trying to pitch in and help maintain the software, not that they're intentionally ignoring you | 18:14 |
| cardoe | Yeah folks are trying to pitch in. | 18:15 |
| cardoe | But when I look back over the past year there was someone else that submitted a patch and even commented after a few weeks "how do I get this reviewed?" | 18:16 |
| cardoe | And they never got any reviews or comments. | 18:16 |
| cardoe | That's what my concern is. | 18:16 |
| clarkb | got it. There is more evidence than just those fixup changes pointing at broader issues. They are just suffering from the same issues | 18:18 |
| mnasiadka | I think if there’s a channel through a community manager - we should explore that path first, before choosing to intervene in a more hands-on approach (if we’re even thinking about it) | 18:18 |
| fungi | yeah, it's been a struggle to get them engaged, which was one of my primnary concerns when the tc first evaluated including that project | 18:20 |
| mnasiadka | But my perception is also that Skyline (and in the past I noticed Venus as well) are a bit closed to the ,,greater OpenStack’’ ecosystem, probably due to cultural differences - and we should try to get that improved? | 18:20 |
| mnasiadka | Well, if that has always been a struggle, then probably another approach via the community manager is not going to improve things a lot. | 18:20 |
| clarkb | this is likely to impact the release too? | 18:21 |
| mnasiadka | Well, somehow skyline is released for 2025.2 | 18:22 |
| mnasiadka | Of course the bot raised patches are not merged due to broken CI, but still the branches are cut. | 18:22 |
| clarkb | I guess the release builds all happen outside of the repo based on the state of the repo when the release changes land | 18:22 |
| clarkb | so the broken gates don't directly impact it | 18:22 |
| clarkb | (we might be releasing broken software but we're still able to build packages and publish them) | 18:22 |
| mnasiadka | So what’s the course of action on this? Was there a similar issue in any OpenStack project in the past? | 18:23 |
| fungi | the main concern for the release is whether the jobs that build python packages work or fail for that project | 18:24 |
| fungi | it looks like skyline-apiserver and skyline-console were last uploaded to pypi in april for the 2025.1/epoxy release | 18:26 |
| fungi | ah, no, pypi doesn't show pre-releases by default, their 7.0.0.0rc1 packages for 2025.2/flamingo are also there | 18:26 |
| fungi | uploaded a week ago, so well after the default ansible version change | 18:27 |
| clarkb | ya I think the risk to the release is if there are updates necessary to build new packages but right now that isn't the case | 18:27 |
| mnasiadka | Ok, need to run - but happy to help with skyline if needed, although don’t know how, if we already tried to communicate with them in the past, and it hasn’t improved the situation. | 18:29 |
| fungi | they don't review release proposals though, e.g. https://review.opendev.org/c/openstack/releases/+/960109 | 18:29 |
| fungi | elodilles commented "no response from team, but deadline is today. generated patch looks good. adding procedural PTL-Approved+1." | 18:30 |
| fungi | granted that change was only up for 4 days | 18:31 |
| fungi | 3 business days in china | 18:31 |
| clarkb | but the gate has been broken for ~1 month | 18:32 |
| clarkb | and changes from other groups are regularly ignored | 18:32 |
| clarkb | its probably reasonable to ask them to diversify the core group given there is interest and they are unable to keep up | 18:32 |
| fungi | yes | 18:33 |
| mnasiadka | Not mentioning they don’t have a weekly meeting | 18:34 |
| fungi | they might, it's just not published on the meetings site and may be on weixin/wechat instead of irc | 18:36 |
| fungi | (so effectively no meeting from the perspective of getting broader community participation anyway)_ | 18:36 |
| gouthamr | the PTL of openstack-helm asked to extend the core team as well: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/4XBC547ICPFIQSM4MM5M5MVZLHJJQ3CR/#H6P4UKCJS52V66RNGLPZUTSBSY66FPCR | 18:50 |
| gouthamr | and wu_wenxiang said yes, but, i think we needed some concrete volunteers to pointed out | 18:51 |
| gouthamr | cardoe: are there folks at RAX that would be a good fit, maybe respond to the thread with the specific gerrit usernames and expression of interest to join the maintainers' team... | 18:52 |
| gouthamr | freyes_: added some questions to https://review.opendev.org/c/openstack/governance/+/962121 | 19:03 |
| gouthamr | gtema: can you please take this poll when you get a chance: https://beta.framadate.org/polls/c49f9bd66948453b9106 | 19:09 |
| tonyb | Do we have a rough plan for picking a meeting time? I don't think I'll be repeating this morning's effort | 19:23 |
| cardoe | Sorry I had to step away. | 21:39 |
| cardoe | Yes I’m trying to get Sowmya to become comfortable enough to volunteer to be a maintainer. | 21:40 |
| cardoe | So I have emailed Wu in the past about contributors and not heard back. I’ve also emailed him about the broken state of the CI. | 21:42 |
| cardoe | My concern is that it’s another project that wants volunteers. People have spoken up. They’ve contributed patches. And then nothing. That leads to losing contributors. | 21:45 |
| gouthamr | +1 for sure; I’ll follow up on the thread you started as well | 21:46 |
| opendevreview | Ian Y. Choi proposed openstack/election master: Close 2026.1 Election Results (TC/PTL) https://review.opendev.org/c/openstack/election/+/961596 | 21:47 |
| gouthamr | tonyb: once gtema responds, we’ll have all the data to decide - I suspect we’ll need two regular slots or atleast a frequent “alternate” slot | 21:48 |
| fungi | cardoe: one thing i'm asking horace is whether the skyline maintainers might have newer e-mail addresses than what's set on their gerrit accounts, because he mentioned something about them moving to a new employer and their addresses are still at 99cloud | 21:59 |
| fungi | so it's possible those e-mails have been going into a black hole | 21:59 |
| cardoe | fungi: absolutely possible | 22:37 |
| cardoe | fungi: but they've gotta communicate with us and update that? | 22:37 |
| cardoe | The most recent submission to the PTL list at https://governance.openstack.org/tc/reference/projects/skyline.html retains the 99cloud email address which I've used. | 22:40 |
| opendevreview | Merged openstack/election master: Close 2026.1 Election Results (TC/PTL) https://review.opendev.org/c/openstack/election/+/961596 | 22:45 |
| opendevreview | Merged openstack/election master: Fix update-governance script https://review.opendev.org/c/openstack/election/+/961776 | 22:47 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!