17:59:09 <tumbleweed> #startmeeting DebConf Video Team weekly meeting 17:59:09 <MeetBot> Meeting started Tue Nov 24 17:59:09 2020 UTC. The chair is tumbleweed. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:13 <tumbleweed> #topic Roll Call 17:59:21 <tumbleweed> Say hi if you're here for the meeting 17:59:24 <tumbleweed> #link http://deb.li/oNCD Agenda 17:59:44 <pollo> 0/ 17:59:46 <lenharo> hi o/ 18:00:07 <phls> hi 18:00:28 <tumbleweed> Glad the brazil video team could make it :) 18:00:43 <tumbleweed> #topic MDCO2 - Video Encoding and publishing 18:01:03 <tumbleweed> I've fixed up 3 videos yesterday, and one more in progress now 18:01:19 <tumbleweed> I think when this one lands, we're done 18:01:25 <pollo> yay! 18:01:25 <tumbleweed> assuming they pass final review 18:01:39 <pollo> I guess you'll publish to YT and PT afterwards? 18:01:51 <pollo> have ve finished trickle-publising on YT for DC20? 18:01:52 <tumbleweed> yeah 18:02:01 <tumbleweed> no, still quite a lot of those left 18:02:06 <pollo> heh 18:02:16 <tumbleweed> we can do these in parallel or just wait for dc20 to finish 18:02:31 <tumbleweed> DC20 is up to: 2020-08-25 22:00:00 18:02:57 <tumbleweed> last day was 29th 18:03:19 <tumbleweed> sreview=> SELECT id, title, apologynote FROM talks WHERE event=8 and apologynote IS NOT NULL; id | title | apologynote 18:03:23 <tumbleweed> -----+-------------------------------+---------------------------------------------------------------------------------- 318 | Open Source Game Achievements | Apologies, the speaker's camera is quite choppy due to a bad network connection. 346 | YIRL engine presentation | Apologies for the poor audio quality. 18:03:28 <tumbleweed> (2 rows) 18:03:30 <tumbleweed> urgh, badly formatted paste 18:03:35 <tumbleweed> 318 | Open Source Game Achievements | Apologies, the speaker's camera is quite choppy due to a bad network connection. 18:03:39 <tumbleweed> 346 | YIRL engine presentation | Apologies for the poor audio quality. 18:03:48 <tumbleweed> those are the unfixables that still have apology notes 18:04:12 <tumbleweed> (btw, the text formatting on that apology note is *really* weird 18:04:23 <pollo> yeah 18:04:47 <tumbleweed> highvoltage: not sure if you want to re-run those with better looking apology notes :P 18:04:48 <pollo> but it doesn't look that out of place with the background we used 18:04:57 <tumbleweed> right, it almost looks intentional 18:05:27 <tumbleweed> #topic MDCO2 - Feedback 18:05:36 <tumbleweed> thoughts on how things went? 18:06:07 <pwaring> very well I thought 18:06:13 <tumbleweed> yeah 18:06:18 <pollo> I think it went well, but as I've mentioned before (we have a topic for that), I'm not happy with the jitsi-pad-share quality 18:06:21 <tumbleweed> no serious screw-ups 18:06:25 <pollo> the Firefox bug was unfortunate 18:06:32 <tumbleweed> nothing broke *too* badly, except firefoxes, yes 18:06:47 <tumbleweed> things I think we could improve: 18:06:57 <wouter> o/ 18:07:00 <wouter> (sorry I'm late) 18:07:19 <tumbleweed> there were some talks that were broken in pre-recording. This maybe could have been picked up with more stringent review. But some of those were last-minute video submissions, so <shrug> 18:07:37 <tumbleweed> It seems some speakers should have been more strongly encouraged to pre-record 18:07:57 <tumbleweed> Ideally, we should have caught the firefox problems in test calls 18:08:50 <wouter> The idea of using SReview for uploads is that it allows normalization of prerecordings to a certain standard codec, which *should* reduce these kinds of surprises 18:08:59 <tumbleweed> wouter: the problem wasn't codecs 18:09:07 <tumbleweed> one of the talks had clipped audio 18:09:08 <wouter> we could try to go back to that too? I can disable bs1770gain SReview-wide if needs be :) 18:09:17 <tumbleweed> highvoltage tried to clean it up in an audio editor, and it helped a bit 18:09:20 <tumbleweed> but it's still awful 18:09:23 <wouter> tumbleweed: no, but we did have issues with a video having red mist 18:09:36 <wouter> which I think was a codec issue 18:09:47 <tumbleweed> yeah, maybe 18:09:53 <wouter> I'm not saying it will fix everything, but it should reduce surprises? or am I being silly here? 18:09:56 <tumbleweed> letting the speaker see a preview of what we're going to play could solve that 18:10:01 <tumbleweed> but only if they see it and sign off on it 18:10:06 <wouter> right 18:10:58 <tumbleweed> BTW, wouter, I dug into that encoding issue more 18:11:02 <tumbleweed> it seems specific to that one video 18:11:13 <tumbleweed> I'll file an upstream bug 18:11:19 <wouter> yeah, I haven't yet had time to look at it in depth 18:11:25 <phls> should we recomend to use Chrome/Chromium for MDCO-BR ? 18:11:26 <wouter> I suspect color encoding confusion somewhere 18:11:43 <pollo> phls: yes 18:11:50 <phls> pollo, ok 18:11:59 <pwaring> Chrome also lets you share a specific tab, and seems to hide the window decoration better than FF 18:12:04 <tumbleweed> wouter: my analysis: https://storm.debian.net/shared/zwpAKwkxwMdtKlBri-7224u9U96VDryz7iw4KmKDp86 18:12:12 <tumbleweed> wouter: test files in ~sreview/tmp/yirl/ 18:12:13 <wouter> are we sure Firefox is causing issues? I thought those were fixed? 18:12:21 <tumbleweed> wouter: yes, we are 18:12:30 <pollo> it's a new bug 18:12:34 <wouter> OIC 18:13:10 <tumbleweed> sharing a tab from chrome is also convenient, because it can be backgrounded (assuming you only *need* to share one tab) 18:13:26 <tumbleweed> shall we move on? 18:13:38 <pollo> yup 18:13:44 <wouter> +1 18:14:05 <tumbleweed> #topic mdcobr2020 - maintenance loop 18:14:20 <tumbleweed> so, these are a list of topics of things we need for mdco2br 18:14:55 <pollo> I think phls gave highvoltage the SVGs needed and the plan was for him to generate the maintenance loop? 18:15:04 <tumbleweed> OK 18:15:07 <phls> yes 18:15:12 <tumbleweed> #action highvoltage to generate a maintenance loop 18:15:19 <tumbleweed> #topic title slides 18:15:27 <pollo> same for that :) 18:15:33 <tumbleweed> #action highvoltage to generate title slides 18:15:38 <wouter> I could do it too 18:15:48 <tumbleweed> #topic jitsi & etherpad links 18:15:53 <wouter> but then I guess if highvoltage is already going to work on it, meh 18:16:13 <tumbleweed> terceiro: are you guys going to pre-generate jitsi and etherpad links like we did for DC20 and mdco2? 18:16:24 <wouter> are we considering going back to the vnc etherpad stuff? 18:16:32 <tumbleweed> wouter: later in the agenda 18:16:34 <wouter> (or is that for a later subject perhaps) 18:16:36 <wouter> right :) 18:16:41 <terceiro> tumbleweed: I think we probably should 18:16:44 <terceiro> I can do that later today 18:16:48 <pollo> and if possible, don't used "mdcobr-" at the beginning of the etherpad slugs :) 18:17:05 <tumbleweed> pollo didn't like that prefix for mdco2 :) 18:17:11 <tumbleweed> pollo: you want the same 32-character slug, though? 18:17:20 <pollo> I don't mind the length 18:17:33 <tumbleweed> OK 18:17:42 <terceiro> FWIW I will just cargo cult the url patterns from mdco2 18:17:46 <tumbleweed> #action terceiro to pre-generate links 18:17:49 <terceiro> minus the hated prefix 18:17:53 <pollo> +1 18:17:55 <tumbleweed> heh 18:18:08 <tumbleweed> you'll also want to set up a video team group / something like that 18:18:18 <tumbleweed> and grant them "view all talks" access 18:18:29 <tumbleweed> so that they can see the jitsi links 18:18:33 <terceiro> ack 18:18:47 <tumbleweed> #topic OBS 18:18:56 <paddatrapper> Sorry in late 18:19:04 <tumbleweed> is highvoltage helping out with OBS setup? 18:19:16 <pollo> I think he started playing around already yes 18:19:28 <tumbleweed> OK, without him here, probably nothing to discuss, then 18:19:49 <tumbleweed> #topic mdcobr2020 - grabber machine 18:20:07 <tumbleweed> we found that for some of our mdco2 volunteers, sharing etherpad via jitsi was impossible on their machines 18:20:15 <tumbleweed> so, maybe it's a good idea to bring back the VNC grabber machine 18:20:25 <phls> please remember me, what is the grabber machine? 18:20:28 <pollo> and even with a good internet connection, the result is full of artifacts 18:20:37 <wouter> phls: the machine we use to show the etherpad 18:20:41 <phls> ok 18:20:44 <tumbleweed> pollo: it's basically just a desktop computer in the cloud, that feeds screen capture to voctomix 18:20:50 <wouter> phls: for mdco2 we told talkmeisters to do it on their machine, but that had issues 18:21:01 <terceiro> tha grabber vm felt a bit clunky to me during dc20 18:21:06 <pollo> it is 18:21:07 <paddatrapper> Yeah I think we should stand up a grabber 18:21:10 <tumbleweed> terceiro: yeah, that's why we dropped it for mdco2 18:21:27 <wouter> but bandwith considerations mean it's a good idea to bring it back 18:21:36 <paddatrapper> I'd rather have it clunky for volunteers than unreadable for attendees 18:21:47 <tumbleweed> if a talkmeister has a good connection they could use jitsi instead 18:22:02 <wouter> paddatrapper: +1 18:22:04 <terceiro> TBH I'm not sure people watching _need_ to the pad in the stream 18:22:05 <tumbleweed> but 2 options is harder to explain to people 18:22:07 <pollo> tumbleweed: that would mean 1 less source though, split-screen on questions is nice 18:22:12 <tumbleweed> pollo: yeah, it is 18:22:19 <tumbleweed> terceiro: agreed 18:22:23 <pollo> that also means we'll need a background loop 18:22:23 <tumbleweed> sometimes the pad is useful, sometimes it isn't 18:22:30 <tumbleweed> pollo: good point 18:22:46 <tumbleweed> do we action highvoltage for that? 18:22:49 <pollo> heh 18:22:50 <CarlFK> the grabber needs VNC so that someone can scroll it, and that's it, right ? 18:22:53 <terceiro> the conf where I discovered this pad thing was GUADEC, and they never showed it on the stream 18:22:54 <wouter> well, you can just keep the default which is a black background 18:22:54 <pollo> CarlFK: yes 18:22:58 <tumbleweed> CarlFK: and load the right pad 18:23:17 <wouter> terceiro: that's actually a good point too 18:23:19 <pollo> tumbleweed: I feel it's useful, especially when people have strong accents 18:23:19 <tumbleweed> I think it's very useful to show the pad during BoFs 18:23:32 <wouter> terceiro: I do sometimes think to myself "I can read too, talkmeister", but... 18:23:34 <pollo> terceiro: :) 18:23:41 <tumbleweed> yeah, some talkmeisters are way too verbose 18:23:45 <tumbleweed> they could be summarizing the questions 18:23:51 <terceiro> IME, when the pad is actively used, it's best if someone involved shares it 18:23:53 <wouter> it's especially silly if the talkmeister reads a question that has *just* been answered, which happened once through the mdco2 18:23:53 <tumbleweed> (or skipping them, if thye've already been answered) 18:24:14 <tumbleweed> jathan: that was you, btw :) 18:24:25 <wouter> tumbleweed: I didn't want to name names, but yes :) 18:24:28 <tumbleweed> we should probably be giving talkmeisters feedback during the conference and improving them 18:24:43 <tumbleweed> it doesn't help if we all think "that was bad" but don't do anything about it 18:24:50 <wouter> true 18:25:07 <phls> i think it's a good idea the speaker and talkmeister see the pad, but not necessary share it on the streaming 18:25:15 <wouter> but then I always feel slightly awkward telling people who've been doing a certain thing a lot more than me how to do that thing 18:25:24 <tumbleweed> yeah 18:25:30 <pollo> I normally read questions even though they've been answered on the pad, I think it's wrong to assume everyone can read the answer on screen 18:26:09 <pollo> anyway, we agreed on a grabber VM :) 18:26:11 <wouter> should we perhaps action someone to write instructions/suggestions for talkmeisters? 18:26:30 <wouter> on etherpad things, I mean 18:26:38 <paddatrapper> wouter: we have documentation for that, but probably needs adding to 18:26:40 <tumbleweed> we do have intructions, this sounsd like a follow-up doc on how to be a better talkmeister 18:26:41 <phls> we will not have problem with accents (i hope) :-) 18:27:05 <terceiro> I would keep things simple, not have a grabber vm, and instead document how talkmeister should handle the pad 18:27:06 <wouter> 'kay 18:27:10 <terceiro> but that's just me 18:27:23 <wouter> terceiro: well, if you prefer not to show the pad, then we also don't need the grabber vm 18:27:40 <lenharo> i guess for now, don't need grabber vm 18:27:49 <terceiro> I seem to be in the minority on this though 18:27:50 <phls> i agree 18:27:55 <tumbleweed> OK, if you change your mind, let us know 18:27:57 <pollo> that's ok then, but we should discourage people to share the pad on jitsi then 18:28:03 <phls> for MDCO-BR at least 18:28:05 <tumbleweed> it's pretty simple to spin up 18:28:08 <wouter> it's up to you, really. I guess a non-english minidebconf has the advantage that more people are likely to speak the language natively 18:28:18 <wouter> which means the added advantage of being able to also read the question is not really there anymore 18:28:22 <paddatrapper> Especially with potential issues with screen sharing on Firefox 18:28:28 <wouter> right 18:28:54 <tumbleweed> #agreed mdcobr2020 does not need a grabber (and expects to show the pad on the stream less than usual for debconf online) 18:29:09 <tumbleweed> #topic mdcobr2020 - test run 18:29:22 <tumbleweed> do you want to do a test run before the weekend? 18:29:37 <tumbleweed> I think it would be a good idea, even if it's just 10 minutes 18:30:00 <phls> yes, sure 18:30:05 <tumbleweed> we should have all of the assets (slides, backrgrounds, etc.) in place before hand, though 18:30:14 <phls> after 21h UTC please :-) 18:30:29 <tumbleweed> you tell me when, and I can be there 18:30:40 <tumbleweed> but maybe we'll have to wait for highvoltage's actions, first 18:30:54 <phls> ok 18:31:23 <tumbleweed> #agreed we'll try to do a test run, once the prerequisite assets are in place 18:31:36 <tumbleweed> #topic volunteers and training 18:31:48 <pollo> I can't help tomorrow, sorry :( 18:31:51 <tumbleweed> I see from the agenda you'll be training on wednesday at 17:30 18:32:18 <wouter> 17:30 UTC? 18:32:26 <tumbleweed> yeah 18:32:35 <pollo> you should make sure volunteers have an account on salsa and log in the conference website 18:32:46 <tumbleweed> phls: I suggest collecting salsa usernames in signup, so we can give them access to https://salsa.debian.org/debconf-video-team/access-credentials 18:33:03 <tumbleweed> and yes, make sure they log into the website so they can be added to the video group and see jitsi URLs 18:33:39 <lenharo> no.. 23:30 UTC 18:33:59 <wouter> oh, so 17:30 local time? 18:34:06 <lenharo> 20:30 local time 18:34:13 <tumbleweed> it says 17:30 UTC in the pad 18:34:24 <phls> tumbleweed, ok for salsa usernames 18:34:30 <wouter> lenharo: 17:30 UTC is an hour ago 18:34:40 <wouter> (for today) 18:35:04 <wouter> lenharo: so would you mean an hour ago tomorrow, or later than that? 18:35:07 <nattie> i think someone calculated the time difference in the wrong direction 18:35:07 <tumbleweed> (by the pad, I mean the agenda) 18:35:10 <phls> sorry, 20:30 local time, 23:30 UTC :-) 18:35:28 <wouter> oh, right, I was confused there, sorry 18:35:28 <phls> I did 20:30 - 3:00 18:35:36 <wouter> aha 18:35:47 <tumbleweed> #info training will be on Wednesday at 23:30 UTC 18:35:50 <phls> :-) 18:35:55 <wouter> okay, 23:30 UTC is quite past my bedtime, so I won't be there 18:36:15 * nattie *might* be able to look in, but is possibly quite busy 18:36:16 <tumbleweed> it will be in pt_BR anyway 18:36:21 <tumbleweed> but I'll be around if you need anything 18:36:25 <phls> cool 18:37:08 <tumbleweed> #topic mdcobr2020 - questions 18:37:26 <tumbleweed> I quote from the agenda: 18:37:27 <tumbleweed> Show clock in UTC-3 18:37:28 <tumbleweed> Ask to update SReview 18:37:48 <tumbleweed> phls: are you talking about the clock in OBS? 18:37:59 <pollo> and likely on voctomix1 ? 18:38:02 <phls> yes, we had a small update on the agenda (just add some speakers on one BoF) 18:38:18 <pollo> I guess it would make sense to use UTC-3 everywhere 18:38:20 <phls> on the streaming, there is a clock on the screen 18:38:26 <tumbleweed> phls: that's OBS 18:38:37 <wouter> let me run the script, sec 18:38:57 <tumbleweed> pollo: yeah, maybe we should be changing the timezone of the machines to -3? 18:39:03 <wouter> eh, can't do it now, but I'll do it tonight 18:39:21 <tumbleweed> wouter: or do you want recording filenames in UTC? 18:39:21 <phls> wouter, thanks 18:39:35 <terceiro> I think only the onscreen clock is fine 18:39:42 <terceiro> or onstream in this case 18:39:54 <wouter> tumbleweed: I want recording filenames in whatever the in-SReview database uses as timezone 18:39:58 <wouter> otherwise things get confused 18:40:08 <wouter> but I can update the script to do that, so just make everything UTC-3 and I'll be happy 18:40:30 <tumbleweed> wouter: right, so what are you doing in your database 18:40:47 <wouter> tumbleweed: I'll make the times there stored in UTC-3? 18:41:07 <wouter> unless you tell me now that that would complicate matters 18:41:11 <tumbleweed> so you'll want UTC-3 filenames 18:41:15 <wouter> yes 18:41:33 <tumbleweed> sounds reasonable to me 18:41:41 <tumbleweed> #agreed we'll record in UTC-3 18:41:43 <wouter> then all the times can be UTC-3 18:42:15 <wouter> I'll also make the script idempotent and then just run it from cron 18:42:24 <tumbleweed> it doesn't seem ideal to be constantly changing timezone in our long-lived infra. But it does seem to make sense for this conference 18:42:28 <wouter> which would mean that any change to wafer will migrate to the db automatically 18:42:34 <tumbleweed> maybe in the future we'll decide this was a bad idea, and try to move to UTC-only 18:42:52 <pollo> #action pollo to update machines for UTC-3 18:42:55 <nattie> it makes sense for .in as well though 18:43:05 <terceiro> IMO this is pretty risky 18:43:07 <wouter> #action wouter to update the schedule in SReview to UTC-3 18:43:10 <terceiro> I would leave the clock in the machines alone 18:43:15 <nattie> since they're on a half-hour offset 18:43:36 <phls> ah, do we need to worry with record the talks during presentations? Or everything is done on background? 18:43:49 <nattie> (sorry for the diversion) 18:43:57 <tumbleweed> phls: we're always recording (or not recording) 18:44:06 <tumbleweed> I mean, we turn it on at the start of the conference, and off at the end 18:44:16 <phls> tumbleweed, ok 18:44:50 <phls> but should we ping someone to start and end it? 18:45:07 <nattie> phls: the whole conference, not just each talk 18:45:09 <wouter> phls: it doesn't hurt, I guess, but it's on our checklist 18:45:11 <nattie> the whole weekend event 18:45:27 <phls> ok 18:45:57 <pollo> paddatrapper: do you know if you'll be able to take the first "on-call" shift? 18:46:08 <pollo> phls: have you seen my ping wrt a wiki page for volunteers? 18:46:24 <paddatrapper> pollo: I'll only know Friday around 17:00 UTC unfortunately 18:46:36 <pollo> ok, well be sure to keep me posted 18:46:40 <paddatrapper> will do 18:46:43 <pollo> I won't get up saturday morning otherwise :) 18:46:53 <tumbleweed> terceiro, pollo: We could also just put TZ=America/Sao_Paulo in the record script (and OBS) 18:47:01 <phls> pollo, lenharo is creating the wiki page 18:47:29 <pollo> tumbleweed: I'm ok with that 18:47:33 <terceiro> tumbleweed: +1 18:47:45 <terceiro> feels a lot safer 18:47:48 <tumbleweed> #agreed insert TZ into record script 18:47:56 <wouter> tumbleweed: I fear that if you do that we may forget one place and then things go horribly wrong? 18:48:08 <pollo> not if it's ansibled 18:48:15 <tumbleweed> wouter: it is a risk 18:48:28 <tumbleweed> but the only interface between voctomix and sreview is those files 18:48:32 <tumbleweed> so I think it's simple enough 18:48:45 * tumbleweed likes servers that run on UTC 18:48:46 <wouter> if it's system-wide and ansibled, and then you reboot the box to be sure... 18:49:00 <wouter> well, if you're sure you can make it work, it's fine I guess 18:49:12 <terceiro> I think we are complicating things. the only request was showing the OBS clock in UTC-3, nothing else is really necessary 18:49:22 <tumbleweed> the files do matter for sreview 18:49:24 * wouter 's server is running in a timezone he hasn't been in for over a year now :) 18:49:50 <tumbleweed> sreview uses tz-aware columns for times 18:49:59 <tumbleweed> but I don't know if it converts to UTC when it comes to deal with files 18:50:04 <tumbleweed> which is why I asked :) 18:50:05 <terceiro> but why is this different from any other conf with its own TZ? 18:50:21 <tumbleweed> terceiro: usually the machines are *on-site* at that conference, and in the local timezone 18:50:24 <wouter> yes, but I haven't actually ran any conference where it looked at that, and I'd rather not start looking now 18:50:26 <tumbleweed> i.e. the thing you didn't want to do 18:50:54 <terceiro> ah 18:50:55 <terceiro> ok 18:50:57 <tumbleweed> CarlFK takes his own machines to conferences, and they're usually still in Chicago timezone, so sreview has built-in hacks for dealing with this mess 18:51:06 <tumbleweed> s/sreview/veyepar/ I meant 18:51:07 <terceiro> omg 18:51:15 <tumbleweed> (he forgets to change the timezone) 18:51:19 <terceiro> heh 18:51:29 <wouter> yeah, I think it's fair to say that SReview assumes everything is in the same timezone 18:51:32 <terceiro> I'll shut up and let the people who know what they are doing alone 18:51:48 <wouter> I originally didn't want to write it that way, but I never ended up testing any code to actually work, and so now, no. 18:52:07 <tumbleweed> :P 18:52:21 <wouter> (aka, "don't look at the database for features that SReview supports") 18:52:33 <wouter> there are entire *tables* in the SReview database that *no* code will ever look at 18:52:40 <tumbleweed> :P 18:52:44 <tumbleweed> yeah, I found that last week 18:52:51 <tumbleweed> OK... 18:53:05 <tumbleweed> so, let's try TZ and see what it looks like 18:53:07 <tumbleweed> #topic video archive documentation 18:53:11 <tumbleweed> paddatrapper: carry the item? 18:53:21 <paddatrapper> pollo you mean? 18:53:28 <tumbleweed> wrong p, oops 18:53:30 <pollo> yes 18:53:31 <paddatrapper> heh 18:53:41 <tumbleweed> #topic Any other Business 18:54:05 <wouter> would someone be so kind to help me set up a play environment of our stuff for fosdem? 18:54:15 <wouter> not before the weekend obviously, but after that 18:54:18 <paddatrapper> wouter: sure 18:54:29 <wouter> I don't know it *quite* well enough, so... 18:54:32 <wouter> thx 18:54:43 <tumbleweed> happy to help out there too 18:54:48 <tumbleweed> if you have infra, we can ansible it :P 18:55:25 <wouter> it's just that I don't really know which parts are required and which parts aren't, and also I don't think we have a gitlab 18:55:42 <tumbleweed> oh, phls, lenharo: 18:55:53 <pollo> wouter: a oAuth2 provider would likely work I guess 18:55:56 <wouter> so either we'll have to set up a gitlab for a play environment (feels like overkill) or we'll have to figure out some other OIDC service 18:56:00 <phls> wouter, will fosdem use the same debconf solution? 18:56:07 <wouter> phls: not decided yet 18:56:19 <tumbleweed> yesterday I tried to help avoid people setting video to a source, without setting audio to it. This happens sometimes. 18:56:30 <wouter> part of why I want this play environment, so I can (hopefully) convince people it's a good idea and we *don't* need to reinvent the wheel :) 18:56:33 <tumbleweed> so, this branch is currently deployed on the conference vogol: https://salsa.debian.org/debconf-video-team/vogol/-/merge_requests/14 18:57:32 <tumbleweed> it looks a little bit different to what we did training on 18:57:53 <wouter> I think it's fine? 18:58:20 <phls> tumbleweed, ok 18:58:39 <pollo> I think it makes it harder if we were to use split-screen, but for a miniconf with only 3 sources it does solve the problem 18:59:02 <tumbleweed> pollo: All of the controls are still there, just moved around 18:59:13 <tumbleweed> and in split screen, it will be obvious which sources are contributing audio 18:59:18 <pollo> yes, but "select" is confusing for split screen 18:59:31 <tumbleweed> I'd also expect a preset for dc20-style Q&A 19:00:00 <pollo> "fullscreen solo" was clearer in that regard imo 19:00:09 <tumbleweed> for a video-only source, it will say: "Select Video" 19:00:12 <pollo> anyway, no need to talk about this during the meeting :) 19:00:33 <tumbleweed> yeah, I just wanted to bring their attention to it 19:00:44 <tumbleweed> suggestions on improvements definitely appreciated :) 19:01:02 <paddatrapper> We may need to update docs and screenshots to reflect the changes? 19:01:08 <tumbleweed> yeah 19:01:12 <nattie> might be worth showing it to people before the training session tomorrow 19:01:21 <tumbleweed> we can hold this change until after the br mini, too 19:01:22 <nattie> (specifically, those conducting the training) 19:01:30 <nattie> fair enough 19:02:45 <tumbleweed> should we do that? go back 19:03:24 <phls> now vogol is updated? 19:03:26 <pollo> I think the current patch makes it better for miniconfs, so I'd say no 19:03:54 <tumbleweed> OK, I'll look at updating docs 19:04:09 <tumbleweed> let's finish this meeting 19:04:14 <tumbleweed> #topic Next Meeting 19:04:24 <tumbleweed> Same time next week? 19:04:35 <wouter> wfm 19:04:37 <pollo> yes, but afterwards, let's take a break :) 19:04:44 <tumbleweed> that'd be nice 19:04:47 <lenharo> yes 19:04:58 <paddatrapper> +1 to both 19:05:05 <wouter> yes please 19:05:06 <tumbleweed> #agreed same time next week. and then HOLIDAYS (until .in mini) 19:05:14 <wouter> regardless, I'll probably be too busy with FOSDEM anyway 19:05:19 <tumbleweed> #endmeeting