| *** vhari_ is now known as vhari | 03:12 | |
| frickler | wow, this actually crashed my meetpad tab. but I was going to drop out anyway soon, so nevermind | 16:38 |
|---|---|---|
| gouthamr | crap | 16:39 |
| gouthamr | ill thought out on my end | 16:39 |
| gouthamr | i got to see _some_ faces before all the chaos | 16:39 |
| fungi | i keep my performance settings at "audio only" since i don't care about seeing anyone's cameras | 16:39 |
| gouthamr | +1 good tip | 16:39 |
| frickler | indeed, I wasn't aware of that option | 16:40 |
| fungi | worth noting it's the in-browser client getting overloaded, because jitsi-meet is peer-to-peer and you're effectively receiving video streams from, like, 50 people or whatever all at once to your browser | 16:40 |
| fungi | in theory, if you have a beefy system and plenty of bandwidth and not much else going on at the time, probably the browser would gracefully render all those | 16:42 |
| gouthamr | which was partially true on my end; i killed everything else for today's calls | 16:43 |
| fungi | yeah, i actually have a separate machine in my lab i use for videoconferencing which normally sits idle doing nothing else | 16:50 |
| gouthamr | i need that | 16:51 |
| * gouthamr remembers bswartz did this sorta thing in the heydays of openstack | 16:52 | |
| TheJulia | gouthamr: I put two training video links on the etherpad regarding the visioning topic | 17:22 |
| gouthamr | ty TheJulia! | 17:22 |
| fungi | cardoe: would your idea of a github pull request closer action replace the one we currently have? | 17:56 |
| cardoe | oh do we have one? | 17:56 |
| cardoe | So I wanted to give the person something friendly. | 17:57 |
| fungi | yeah, it closes all pull requests with a thanks and a link to our contributing instructions, but it's configurable | 17:57 |
| JayF | Where's that action kept at? | 17:57 |
| JayF | like, where in github can I find it? | 17:57 |
| cardoe | Yeah that'd be perfect. I was doing something with reading pyproject.toml for example. | 17:57 |
| cardoe | I wanted to allow projects to configure their docs and such. | 17:58 |
| mnaser | its not a github action right now, its just a seperate project i believe? | 17:58 |
| fungi | https://opendev.org/openstack/project-config/src/branch/master/playbooks/maintain-github-mirror/github_manager.py#L36-L52 | 17:59 |
| mnaser | https://github.com/openstack/kolla-ansible/pull/66#issuecomment-3524876635 e.g | 17:59 |
| JayF | oh, neat | 18:00 |
| JayF | we could potentially obviate this code with the repo I proposed | 18:00 |
| JayF | and/or use this code instead of the repo I proposed (probably a worse idea given it has gitea downsides) | 18:00 |
| fungi | well, the alternative (which sounded better to me, but opinions vary i'm sure) was to just disable pull requests in github now that they've finally made it possible | 18:01 |
| mnaser | indeed yes its been a few months: https://github.blog/changelog/2026-02-13-new-repository-settings-for-configuring-pull-request-access/ | 18:02 |
| JayF | yeah mainly I'm going to focus on getting the bits setup for us to have a .github repo | 18:03 |
| JayF | then proposing configs to it will be a more group effort | 18:03 |
| clarkb | they finally made that change due to LLM contribution spam/slop too | 18:03 |
| cardoe | So forever ago I wrote something for Xen on GitLab which we were getting contributions from to actually take the PR and split out the changes with "git patch-format | git am" to the mailing list. And it put a header with the GitLab merge request link in there. Email replies usually worked back to GitLab too unless someone's client was super weird. But if the person pushed an update it would splat the patch series as v2 or | 18:06 |
| cardoe | higher. | 18:06 |
| cardoe | But they had an email address that could be replied to for comments on the merge request. | 18:06 |
| cardoe | They were recently updating it and I got CC'd on the patches for that setup. Which is what made me think about how to lessen the friction for contributors. | 18:08 |
| cardoe | It does nothing to solve the review bottlenecks however. | 18:08 |
| fungi | yeah, also gerrit itself *does* actually support review by e-mail, but we don't have the inbound receipt bits for that plumbed on our server | 18:11 |
| clarkb | also historically that was considered problematic due to the CLA. I'm not sure if the DCO changes that (it might) | 18:24 |
| clarkb | that == moving someones contribution from github to gerrit automatically for them | 18:24 |
| fungi | well, this is more about being able to send review comments by e-mail reply | 18:33 |
| clarkb | oh I read doing the git patch formatting pass to the mailing list as trying to get the code from one place to another. | 18:35 |
| fungi | yeah, sorry, my comment was about review-by-mail in gerrit, specifically, not about patch submission | 20:08 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!