| slaweq | thx for the feedback frickler, so I won't do anything with this then. I personally don't really understand such approach and why we should really defend against LLMs but that's just my humble opinion :) | 07:00 |
|---|---|---|
| fungi | slaweq: mainly because the operators of at least some of these llms aren't being conscientious and considerate of the resources they're consuming on everyone else's systems by inefficiently re-crawling the same content over and over at a breakneck pace. ~everyone who runs a webserver now says that 99.9% of all their web traffic is llm training bots, so they're putting a | 13:17 |
| fungi | thousand-fold increase in load on the internet infrastructure | 13:17 |
| fungi | i'm sure they think that wasting everyone else's time, money and resources in the pursuit of profit/success is an acceptable compromise, but a lot of people on the other side of that equation disagree | 13:19 |
| fungi | on the opendev servers we've been forced to waste lots of volunteers' time implementing and maintaining elaborate solutions for filtering/blocking the llm training crawlers, just to keep everything running | 13:21 |
| fungi | my personal webserver is offline about 25% of the time due to getting overwhelmed by them too | 13:22 |
| slaweq | gotcha, thx for explanation | 13:24 |
| fungi | one of the major cdn companies (cloudflare?) months ago started advertising a feature where users could flip a switch to just automatically block llm training crawlers from reaching any of their content | 13:26 |
| clarkb | fungi: cloudflare just launched (or maybe just announced) a feature where they will block crawlers unless they pay for access | 14:52 |
| clarkb | so cloudflare is figuring out how to monetize the situation to their advantage | 14:52 |
| gmaan | In case anyone would like to join, Board meeting is in-progress | 15:04 |
| fungi | first meeting of the new openinfra governing board is underway if anyone's interested: https://board.openinfra.org/meetings/2025-07-08 | 15:04 |
| gouthamr | missed that ^ hope one of you can recap during the tc meeting, speaking of which: | 16:02 |
| gouthamr | tc-members: gentle reminder that we are meeting here in ~58 minutes | 16:02 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Jul 8 17:00:07 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:00 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:00 |
| gouthamr | #topic Roll Call | 17:00 |
| spotz[m] | o/ | 17:00 |
| gtema | o/ | 17:00 |
| gmaan | o/ | 17:00 |
| bauzas | o/ | 17:01 |
| frickler | \o | 17:01 |
| mnasiadka | o/ | 17:02 |
| gouthamr | courtesy-ping: noonedeadpunk, cardoe | 17:03 |
| noonedeadpunk | o/ | 17:03 |
| noonedeadpunk | sorry | 17:03 |
| cardoe | Sorry. I’m getting to my computer. I’m on mobile. | 17:03 |
| gouthamr | no problem, hello everyone | 17:04 |
| gouthamr | thanks for joining, lets get started | 17:04 |
| gouthamr | #topic Last Week's AIs | 17:04 |
| gouthamr | bauzas: we took one on the eventlet timelines change on gerrit | 17:04 |
| bauzas | thanks | 17:04 |
| gouthamr | i.e., to follow up on the comments so far | 17:05 |
| bauzas | sorry had no time to update it | 17:05 |
| bauzas | anything to summarize ? | 17:05 |
| gouthamr | nope, i think we were trending towards a consensus on the proposal.. there are a few comments to clarify that | 17:05 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/952903 (Make Eventlet removal deadlines more acceptable for operators) | 17:05 |
| bauzas | okay, I'll try to update it this week | 17:06 |
| gouthamr | thanks, next up was pbr.. | 17:06 |
| gouthamr | i did see some changes up to fix the broken gate | 17:07 |
| gouthamr | and start the pkg_resources removal | 17:07 |
| gouthamr | #link https://review.opendev.org/q/topic:%22pkg_resources-removal%22 | 17:07 |
| gouthamr | thanks stephenfin \o/ | 17:07 |
| gouthamr | we took an AI to cleanup mentions of the CLA | 17:08 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/953843 (Remove mentions to CLA in licensing guide) | 17:08 |
| gouthamr | this was merged yesterday | 17:08 |
| gouthamr | there are still some mentions in project specific contributor documentation | 17:09 |
| gouthamr | i'll send a note to project teams to clean that up | 17:09 |
| gouthamr | the last AI i see is the TC meet-and-greet session at the Summit | 17:10 |
| gouthamr | spotz[m]: was this submitted? will you be leading it? | 17:10 |
| spotz[m] | I haven’t yet but will | 17:11 |
| gouthamr | ack ty spotz[m] | 17:11 |
| * spotz[m] uploaded an audio file: (32KiB) < https://matrix.org/oftc/media/v1/media/download/ARvCChTu9DoS1D8sq9-Af1AB40TseHVd8cyCDkBfPTo4mUUB2zq6i5f1-4w7JHa1fA7grDXZUDaYJ7vK2ka3lpJCeYMx6XBAAG1hdHJpeC5vcmcvdVd5Z1BhRkRpSVJra2tkWlVXT2dwY1dq > | 17:11 | |
| gouthamr | a cryptic voice note? :D | 17:11 |
| gouthamr | a reminder for other folks here considering a forum session or project update session for the summit, that the deadline is today | 17:12 |
| spotz[m] | Me playing with app | 17:12 |
| gouthamr | that's all the AIs i see, was anyone working on anything else? | 17:12 |
| gouthamr | #topic A check on gate health | 17:14 |
| gouthamr | any gate updates this week? | 17:14 |
| clarkb | there were a few more multinode hiccups related to zuul-launcher providing mixed cloud nodesets. Several bugs around that have been fixed. Hopefully it doesn't happen anymore | 17:15 |
| mnasiadka | And hopefully CentOS 10 Stream and Rocky Linux 10 nodes should be available this week, there's a light in the tunnel ;-) | 17:16 |
| noonedeadpunk | I was just about to ask about this ^ | 17:16 |
| fungi | also debian-trixie, probably | 17:16 |
| noonedeadpunk | that would be also really nice to have once eventlet not really a blocker | 17:17 |
| gouthamr | ++ | 17:18 |
| gouthamr | i'd like not to jinx the gate bang in the middle of the cycle, but this all sounds like good news | 17:19 |
| gouthamr | anything else for $topic? | 17:19 |
| bauzas | hmmm | 17:20 |
| bauzas | I'll be at the Summit, got green light | 17:20 |
| noonedeadpunk | \o/ | 17:20 |
| bauzas | but in case we want to run a session like meet-and-greet with ops, sure I can help | 17:20 |
| bauzas | I'm not having any Forum session | 17:20 |
| fungi | or jetlag ;) | 17:20 |
| gouthamr | :P | 17:21 |
| fungi | (envious) | 17:21 |
| gouthamr | #topic TC Tracker | 17:21 |
| noonedeadpunk | oh, I might have one for you bauzas :p | 17:21 |
| gouthamr | we have some open patches that could use more reviews: | 17:21 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/governance+status:open | 17:22 |
| gouthamr | elod proposed the retirement of Monasca, and it looks like we need a few more things per the retirement process | 17:25 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/953671 | 17:25 |
| gmaan | yeah, it is already inactive since many cycle | 17:27 |
| gouthamr | i dont know if the PTL would object to this.. | 17:27 |
| gouthamr | there's been no activity in the project itself | 17:27 |
| gouthamr | #link https://review.opendev.org/q/project:%5Eopenstack/monasca-.* | 17:27 |
| gmaan | I will say keep it inactive and this election we will have more clarity if anyone step up | 17:27 |
| gmaan | if any volunteer then we can have question for them about plan as it has been inactive for many cycle | 17:28 |
| gouthamr | ack, feels like users/operators are keeping it alive | 17:28 |
| gouthamr | #link https://review.opendev.org/q/topic:%22upgrade_monasca%22 | 17:29 |
| gouthamr | ^ these are the last tangible changes | 17:29 |
| gouthamr | that sounds fine gmaan, but, even if the PTL re-nominates themselves, it looks like this is in "maintenance mode" of sorts | 17:30 |
| gouthamr | if something major breaks in the dependencies (e.g.; eventlet), this could fall apart | 17:31 |
| gmaan | sure but as we do not have separate status like 'maintenance mode' for projects either it should be active as per governance requirement or inactive or retire | 17:31 |
| gouthamr | yeah | 17:31 |
| gmaan | and the requirement we have to keep it active is not so much, it is similar to any 'maintenance mode' software like many projects are in same situation | 17:32 |
| gmaan | current maintainers are not marking it active if it is so we do not know the actual situation | 17:32 |
| gmaan | as per process, it should be retire by now but we do not need to be pro-active for retirement and can give time if maintainers need | 17:33 |
| * gouthamr copies hasan acar and thuvh to the change | 17:33 | |
| gouthamr | maybe we can use the change to discuss their plans if any, and offer advice if they have questions | 17:34 |
| gmaan | yeah, we did in past and PTL agree to the plan but things got disappear | 17:34 |
| gouthamr | true | 17:36 |
| gmaan | I am not against of starting retirement or at least putting it in ML but as it is already marked inactive we know the situation. | 17:36 |
| gouthamr | ack, if there's no response on the change, we can hit the ML | 17:36 |
| gmaan | it is matter of whether we want to give more time to them. | 17:36 |
| gmaan | ++ | 17:36 |
| gouthamr | #topic Open Discussion | 17:36 |
| fungi | and will be excluded from the coordinated release, removed from overview diagrams of the software, et cetera | 17:36 |
| gouthamr | ^ after retirement? | 17:36 |
| frickler | usually inactive is meant to only last one cycle, we are at how many now, 3? | 17:37 |
| gmaan | it is already excluded from release for many cycles | 17:37 |
| gouthamr | they're not a part of the release | 17:37 |
| fungi | no, currently. inactive deliverables are not included in the coordinated release | 17:37 |
| fungi | and we typically don't include them on the software map and such | 17:37 |
| gouthamr | ah, i didn't know that | 17:37 |
| gmaan | frickler: true, we also provided extension to inactive phase | 17:37 |
| gouthamr | there's no warning on the documentation either correct? a la retired projects? | 17:37 |
| gmaan | #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects | 17:38 |
| frickler | so 4 cycles now | 17:38 |
| gmaan | yeah, no warning for inactive projects. I remember artem or someone mentioned about in past PTG about showing some warning or status for inactive projects more wider than just TC doc | 17:39 |
| fungi | good point about docs, we make it look more active by continuing to publish a https://docs.openstack.org/monasca-api/latest/ with a banner stating "This release is under development. The current supported release is 2025.1." | 17:39 |
| gmaan | and that can be good idea to inactive status on doc but we need to implement it | 17:39 |
| fungi | (neither of those sentences being true wrt monasca) | 17:39 |
| gmaan | yeah | 17:39 |
| noonedeadpunk | I think this is assigned to me right now | 17:39 |
| noonedeadpunk | and I can't say I had any progress :( | 17:40 |
| gmaan | noonedeadpunk: ++ | 17:40 |
| mnasiadka | Seems I'm sort of done with centos/rocky10 - so I can try to help with that if needed | 17:40 |
| gouthamr | that would be super helpful.. its monasca now, but we could use a template/documentation note to alert users like we have for retired projects for any other inactive projects in the future | 17:42 |
| gmaan | yeah, basically we need to define what we could show in the /latest or README.rst which is more of temporary status and ask for help | 17:43 |
| gmaan | that should not sounds like this project is retired or cannot be active/ready to use again | 17:43 |
| fungi | this ties in really nicely with some of the things the foundation community managers have been discussing recently too | 17:44 |
| fungi | trying to brainstorm ways to better communicate to the right people when projects need help | 17:44 |
| gmaan | mnasiadka: thanks for help, once you have something up. I will be happy to review. | 17:44 |
| fungi | (historically we've failed at that over and over, with at least half a dozen different solutions tried) | 17:45 |
| gmaan | IMO, this is little different situation. I will say "if you are using/interested in this project then it need help otherwise maybe retiring in future" | 17:46 |
| mnasiadka | fungi: I'd be happy to know which solutions failed before I try them again :) | 17:46 |
| gmaan | and projects we cannot effort to go away like QA, keystone etc can be projected as "projects need help" | 17:46 |
| fungi | mnasiadka: off the top of my head, the project managers working group, the architects working group, the hidden influencers working group, the help wanted list, upstream investment opportunities... | 17:47 |
| fungi | keep in mind this is a history of struggles and attempted solutions stretching back 15 years | 17:47 |
| spotz[m] | What about a header on the doc itself aka larger font saying the last release | 17:48 |
| gouthamr | yeah, we call that header a "badge" in the openstack manuals repo | 17:49 |
| gouthamr | and there's a "deprecated" badge template too | 17:49 |
| gouthamr | #link https://opendev.org/openstack/openstack-manuals/src/branch/master/www/templates/deprecated_badge.tmpl | 17:50 |
| gouthamr | so for an inactive project, we could properly reflect the last (real) release similarly | 17:51 |
| gouthamr | and probably add a similar banner asking for help/new maintainers | 17:51 |
| mnasiadka | well, isn't what we all need are some updates to www-generator.py pointing out such projects? | 17:54 |
| gouthamr | yes | 17:55 |
| gouthamr | currently that has the logic for RETIRED_REPOS, so we should make it look at inactive ones too | 17:56 |
| gouthamr | might have to yank the RST list out of the https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects page and make it a yaml | 17:56 |
| mnasiadka | Nice, I feared my approach is too naive - but I can work on this pointer :) | 17:56 |
| gouthamr | thank you mnasiadka | 17:57 |
| gouthamr | alright, three minutes left, anything else for the minutes? | 17:57 |
| spotz[m] | Mine was more naive:) | 17:57 |
| gouthamr | fungi clarkb: will this ever go away? https://review.opendev.org/static/cla.html | 17:59 |
| fungi | yes | 17:59 |
| fungi | it's on my near-term priority list once we rip out cla enforcement from the non-openinfra project acls in opendev | 17:59 |
| gouthamr | i still see all three agreements under https://review.opendev.org/settings/new-agreement | 17:59 |
| gouthamr | i dont know if there's a use case for any of these now that we don't require it | 17:59 |
| gouthamr | ah | 18:00 |
| gouthamr | i see | 18:00 |
| fungi | there are not, no | 18:00 |
| fungi | all of those will go away | 18:00 |
| gouthamr | thanks for confirming! | 18:00 |
| gouthamr | spotz[m]: all the new contributor workshop/presentation material will need slight tweaking (for the better) to remove CLA stuff :) | 18:01 |
| clarkb | we have a handful of gerrit image rebuild reasons piling up | 18:01 |
| clarkb | the updates tothe zuul status page, cleaning up cla stuff, moving to quay | 18:01 |
| gouthamr | nice | 18:01 |
| clarkb | we may be able to bundle them all together and roll that out at once. I'll bring it up in our meeting later today | 18:01 |
| gouthamr | thanks clarkb | 18:01 |
| gouthamr | alright, we've passed the hour.. thank you all for attending | 18:01 |
| spotz[m] | I’ll take a look at that as I actually was showing it to someone today | 18:01 |
| spotz[m] | Thanks all | 18:01 |
| gouthamr | ty spotz[m] | 18:02 |
| gouthamr | #endmeeting | 18:02 |
| opendevmeet | Meeting ended Tue Jul 8 18:02:03 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-08-17.00.html | 18:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-08-17.00.txt | 18:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-08-17.00.log.html | 18:02 |
| cardoe | So we can no longer backport patches that don't have a signed-off-by? | 18:14 |
| cardoe | Trying to start a backport of https://review.opendev.org/c/openstack/nova/+/948061 to stable/2024.2 | 18:14 |
| jbernard | cardoe: i think that's correct, you can cherry pick from the command line -x and add -s | 18:14 |
| gouthamr | ++ | 18:15 |
| cardoe | okay | 18:16 |
| jbernard | cardoe: not sure if the UI button has been updated to handle this | 18:17 |
| clarkb | at least some of the gerrit web ui rebase/cherrypick type actions allow you to edit the commit message and you can add a signed off by there too | 18:17 |
| gouthamr | you could do it in the gerrit UI too, just add the signed off line | 18:17 |
| clarkb | gouthamr: ya that | 18:17 |
| clarkb | and this is a temporary problem. Once we're sufficiently past the transition point you won't need the extra step as the rule will already be satisfied everywhere | 18:18 |
| cardoe | I'm trying the gerrit UI. I picked cherry-pick and targeted stable/2024.2 and it just throws an error dialog with only a dismiss option | 18:18 |
| clarkb | cardoe: in the menu that opens after you click cherry pick it gives you the commit message. Edit it | 18:19 |
| clarkb | or alternatively pull it locally and use git commit -s and then push to the target branch | 18:19 |
| jbernard | i have a cinder patch that adds a driver call-home feature defaulting to enabled: https://review.opendev.org/c/openstack/cinder/+/951829 I'm curious if we have a policy for this, or existing precedence. Is there any reason to push back on something like this? | 18:24 |
| clarkb | the precedent I can remember was many many years ago lifeless wanted to add metrics gathering that phoned home to gather usage and failure details for openstack as a whole similar to ubuntu's error and usage reporting system. That was pretty handily shot down at the time | 18:26 |
| clarkb | hard enough that it was never implemented as an optional feature either | 18:26 |
| jbernard | clarkb: if you come across an reference to that, i would be interested | 18:28 |
| fungi | definitely at least some redistribtors are going to disable that because of their own distribution policies too | 18:28 |
| fungi | e.g. debian has a nothing-phones-home policy for anything they package | 18:29 |
| fungi | so having it on by default creates additional work for package maintainers | 18:29 |
| jbernard | yeah, this is where i land as well | 18:29 |
| jbernard | exactly | 18:29 |
| jbernard | the default is what bothers me most, i think | 18:29 |
| gouthamr | there’s precedence for this though.. one thing I was telling jbernard was that the NetApp drivers in cinder and manila do this by default | 18:30 |
| gouthamr | the information they gather is what operating system, what version of cinder/Manila are they running | 18:31 |
| jbernard | i just want to make sure that the stance i take is consistent with openstack policy, and not solely personaly opinion | 18:31 |
| fungi | strictly from an "openstack governance policy" perspective, i don't think there's anything official one way or the other | 18:31 |
| fungi | at least not yet anyway | 18:32 |
| gouthamr | yeah.. agree | 18:32 |
| fungi | but it's certainly the sort of thing the tc *could* be asked to decide | 18:33 |
| gouthamr | if we need to push back, we’ll need to also rip out other parts of the stack where this happens (i.e other drivers in cinder/nova/ironic/neutron/manila/etc) | 18:34 |
| clarkb | as an operator I despise any default phone home behavior... The first thing I do when I install firefox or ubuntu is track down all the ways I can to turn that off. Gitea phones home to check if there are new versions available. I think etherpad had/has something too. Its just annoying and bad and shouldn't be on by default | 18:34 |
| clarkb | but that is my personal opinion | 18:34 |
| fungi | that's also one of the reasons i like debian's firefox packages, they turn off all that behavior by default | 18:34 |
| gouthamr | me too, but, there’s probably a way for the operator to disable the phone home behavior on the storage box? | 18:34 |
| gouthamr | the phone home isn’t happening from OpenStack | 18:35 |
| gouthamr | only information gathering is from what I can tell | 18:35 |
| fungi | oh, reporting system information to the nas is less worrisome, from my perspective | 18:37 |
| fungi | if the driver is forwarding information directly to an outside remote system, that's what would bother me | 18:38 |
| gouthamr | +1 I’d be opposed to adding on-by-default phone home capabilities to OpenStack software (how would we do this?)… but from my understanding, these are third party storage drivers gathering what version of OpenStack and what OS is running to their storage systems for the externally configured phone home … | 18:39 |
| gouthamr | maybe the foundation/project maintainers would like an opt-in phone home for questions we currently ask in the user survey… I recall this was a product-wg discussion a long while ago | 18:41 |
| fungi | yeah, the way i've seen that work in other projects is you provide a feature in the software or a separate lightweight tool that assembles the report and shows you *exactly* what's in it, then gives you a convenience button for submitting that to the remote aggregator but also giving instructions on how to manually submit that report just in case you don't trust the button | 18:52 |
| clarkb | jbernard: fwiw I looked through old design summit lists for grizzly, havana, icehouse, and juno (the rough era where I thought that happend) and can't find the discussion | 19:28 |
| jbernard | clarkb: thanks | 19:29 |
| jbernard | ive left a -1 for now, we'll see how things unfold | 19:30 |
| jbernard | appreciate the input | 19:30 |
| spotz[m] | TC Meet and greet is submitted, if anyone wnts to be added to it let me know | 19:57 |
| fungi | worth noting, https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/7CITYVVCQDVJSCK65LOKTN25HWKAM237/ will also be necessary for anyone to be able to run or vote in technical elections (not the 180 day waiting period, but need to explicitly renew to dodge the membership purge) | 21:59 |
| gouthamr | ugh, too many questions… this is kinda hitting us sideways? were we aware of this from a while? If yes, why didn’t we provide a longer timeline? Tech issues? will this email be sent to each foundation member? | 22:05 |
| fungi | i think it was kind of assumed, the old foundation is being dissolved, so anyone who was a member of it isn't automatically a member of the new directed fund in lf | 22:07 |
| fungi | legally speaking | 22:07 |
| fungi | for the same reasons the old contributor license agreements don't apply | 22:08 |
| fungi | the other voting member classes (platinum and gold) have already signed new membership agreements, individual was saved for last partly because it's special from an lf perspective (other member classes also have to be lf members, but individual members don't) | 22:09 |
| fungi | silver and associate member agreements are still being worked through because there are a lot | 22:10 |
| gouthamr | that makes sense, but, the board transition happened a few weeks ago? | 22:10 |
| gouthamr | we could have people that’ll be off the rolls for the next board elections because they’re out/away for the next 10 days - or didn’t read emails sent to foundation or openstack-discuss lists | 22:10 |
| gouthamr | or am I freaking out without reason? | 22:10 |
| fungi | officially? i think it happened a few hours ago when the new governing board met for the first time | 22:10 |
| gouthamr | oh | 22:10 |
| gouthamr | then, couldn’t we postpone elections? Presumably there are tens of thousands of individual members that’ll need to click buttons? | 22:11 |
| fungi | i don't know the answer to that, but am relaying comments to wes | 22:12 |
| gouthamr | ++ | 22:14 |
| gouthamr | thank you.. | 22:14 |
| fungi | will let you know whatever i know | 22:15 |
| fungi | not that it helps, but it's been a nonstop scramble for everyone on staff too | 22:15 |
| gouthamr | i know :( | 22:16 |
| gouthamr | it’s certainly the messenger that’ll get in the line of fire, unfairly; but, sometimes we’ve come up with absolutely reasonable plans when we elicit feedback | 22:17 |
| fungi | fun things like getting a mere few weeks to complete several solid days worth of "new employee" training while still having full-time job responsibilities on top of it | 22:17 |
| gouthamr | yikes :( | 22:18 |
| fungi | clearly their employee onboarding assumes you're coming in fresh with no other actual work or deadlines | 22:18 |
| fungi | which, to be fair, is probably the case most of the time (just not for any of us) | 22:19 |
| gouthamr | are you all onboarded though? I saw a really really cool staff update on the board mailing list when the last board meeting was called off - I think a lot of work went into that.. kudos! | 22:19 |
| fungi | yeah, at least i think we are! fingers crossed | 22:20 |
| gouthamr | the membership reinstatement thingy was one click as promised - just log in and click a button… but still, I’d wonder how many people will do it by July 19th | 22:22 |
| fungi | yeah, i mean i tested it earlier today and it was as described, but i'm reminding them that not everyone even subscribes to the mailing lists, so direct per-member outreach is being considered now (also the possibility of postponing director elections for 2026 if not enough people renew by the original deadline) | 22:24 |
| gouthamr | great stuff, thank you | 22:25 |
| fungi | i don't think they have enough leeway to delay board activities more than an week or so, but even that would almost double the available time for people to get the message before the 180-day deadline | 22:26 |
| gouthamr | +1 | 22:27 |
| spotz[m] | I know on the Fedora matrix we can spam announce things is that an option? I know not everyone is on the channels though | 22:35 |
| fungi | some folks have done that in the past to irc channels with opendev's statusbot | 22:37 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!