17:58:53 <paddatrapper> #startmeeting
17:58:53 <MeetBot> Meeting started Thu Jul  2 17:58:53 2020 UTC.  The chair is paddatrapper. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:53 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:00 <paddatrapper> #topic roll call
17:59:04 <paddatrapper> Agenda: http://deb.li/oNCD
17:59:13 <pollo> 0/
17:59:14 <paddatrapper> Please say hi if you're here for the meeting
17:59:19 <tumbleweed> o/
17:59:21 <olasd> hi if you're here for the meeting
17:59:23 <wouter> I forgot again
17:59:24 <mujeebcpy[m]> hi
17:59:35 <wouter> (actually not, but hey)
17:59:42 <ivodd> hi
18:00:26 <paddatrapper> #topic Action items from last meeting
18:00:43 <paddatrapper> tumbleweed: have you had a chance to create the 4 issues on salsa?
18:00:48 <pollo> heh
18:00:55 <tumbleweed> no! I just thought about that yesterday :P
18:01:07 <paddatrapper> heh no worries
18:01:14 <phls> hi
18:01:16 <wouter> yeah, the issue page is still empty
18:01:20 <paddatrapper> #action tumbleweed to create issues for the 4 pending action items
18:01:54 <paddatrapper> #topic Video Stack
18:02:05 <paddatrapper> pollo: you've been playing around with Vocto?
18:02:10 <olasd> (no progress on my side at all)
18:02:31 <pollo> yes!
18:02:36 <highvoltage> o/
18:02:55 <pollo> so I did sucessfully run the FOSDEM voctoweb frontend
18:03:12 <paddatrapper> #info pollo successfully ran the FOSDEM voctoweb frontend
18:03:15 <pollo> I think it works well enough and can be easily customized to for our needs
18:03:29 <paddatrapper> awesome
18:03:31 <pollo> my next step would be to re-work their ansible role
18:03:38 <wouter> yeah, it's a bit ugly
18:03:45 <wouter> I looked at doing that a while ago, but meh
18:03:46 <tumbleweed> I spun up a voctocore to play with
18:03:56 <tumbleweed> so, we should stick a voctoweb to it
18:04:01 <pollo> I also managed to playback videos to voctomix from the CLI
18:04:04 <pollo> using "$ voctomix-ingest --video-source file --video-attribs "location=foobar.mkv"'"
18:04:17 <pollo> worked well, but I didn't check audio
18:04:23 <pollo> tumbleweed: yes, that's my next step
18:04:32 <wouter> maybe we should make it possible to control that from the web frontend, too?
18:04:32 <ivodd> the main issue with audio is that it needs to change with the source
18:04:34 <pollo> having that will let me check for audio synx
18:04:37 <ivodd> which is different from our normal setup
18:04:50 <paddatrapper> #info we can play video files using voctomix-ingest, but not tested audio yet
18:04:52 <wouter> ivodd: ah yes, good point
18:05:03 <pollo> ivodd: that can be a command passed to vocto
18:05:06 <paddatrapper> #action pollo to test audio sync
18:05:17 <pollo> it's not very hard to do, we'll need to make presets anyway
18:05:30 <paddatrapper> #action pollo to add voctoweb frontend to video team's voctocore VM
18:05:34 <wouter> pollo: if the pre-recorded talks are available, maybe we could have a link in the voctoweb thing to say "start playing the video now"?
18:05:41 <pollo> wouter: yes, that's the idea
18:05:45 <wouter> i.e., have a list of videos etc
18:05:46 <wouter> right
18:05:57 <wouter> and then that link can try to ensure that audio works, too
18:05:59 <pollo> olasd volunteered to add a list of available recordings to voctoweb
18:06:08 <wouter> cool, so that's great then
18:06:15 <paddatrapper> #action olasd to add a list of available recordings to voctoweb
18:06:16 <olasd> yeah, I'll look at that during sprint (I took friday off of work)
18:06:25 <pollo> that's it for me
18:06:31 <ivodd> paddatrapper: #info we got VMs from infomaniak to host our infra
18:06:41 <paddatrapper> #info we got VMs from infomaniak to host our infra
18:07:09 <olasd> (and Monday 13/Tuesday 14th are vacation days too, which I may use for sprint overflow tasks :P)
18:07:19 <paddatrapper> are there any points in that that need mentioning?
18:07:21 <paddatrapper> tumbleweed: ?
18:07:45 <tumbleweed> busy fighting with the nvidia card in the one VM with a GPU
18:07:51 <tumbleweed> haven't got it to work yet
18:08:02 <paddatrapper> though if we have working Vocto do we need GPUs?
18:08:02 <wouter> tumbleweed: do we need that if we're going to use vocto?
18:08:05 <paddatrapper> heh
18:08:06 <tumbleweed> But, on the flip side, OBS seems to work on llvmpipe, if you throw enough CPU at it
18:08:07 <wouter> I thought it was only necessary for OBS
18:08:18 <tumbleweed> wouter: Still keeping options open there
18:08:24 <wouter> fair enough
18:08:24 <pollo> I think tumbleweed's tests with OBS are worth it
18:08:42 <wouter> though I understand it needs a lot more CPU than vocto does?
18:08:43 <ivodd> OBS needs/wants GPU, vocto doesn't
18:08:49 <paddatrapper> #info GPU instances with nvidia cards don't work as expected at the moment
18:08:52 <pollo> at least for now. I'd still prefer it if we can use vocto, but options are a good thing to have
18:08:53 <wouter> if so, I'd be reluctant to use it if we can avoid it
18:08:57 <tumbleweed> wouter: OBS composites with GL, as I understand it
18:08:59 <wouter> true
18:09:17 <wouter> don't get me wrong, I agree that it's good to test
18:09:27 <wouter> but if we don't resolve the nvidia issues, I'd rather go with vocto than with OBS
18:09:28 <paddatrapper> #action tumbleweed to investigate OBS on the GPU instance, to keep options open
18:09:31 <tumbleweed> so, on the infomaniak VMs
18:09:43 <wouter> even if we can get stuff to work, I would rather have something that doesn't nearly max out our VMs
18:09:53 <tumbleweed> aside from the GPU one, they seem to be on a private v4 network, with NATed public IPs
18:09:58 <tumbleweed> and public IPv6
18:10:10 <tumbleweed> connectivity between them seems reasonable
18:10:22 <tumbleweed> no reason to think we can't use them for all of our infra, at this point
18:10:23 <wouter> didn't zigo say it was 10Gbit?
18:10:33 <tumbleweed> yeah. Although that 10gbit will be shared by other users
18:10:38 <wouter> sure, but still
18:10:50 <tumbleweed> are you saying that's good, or bad?
18:10:51 <paddatrapper> #info infomaniak VMs are on a private v4 network, with NATed public IPs and public IPv6. Good conectivity between them
18:10:58 <wouter> I'm saying it's definitely not bad
18:11:00 <olasd> as long as we don't let wouter use all these 10gpbs for sreview ;p
18:11:05 <wouter> olasd: heh :)
18:11:14 <pollo> tumbleweed: but we'll keep using the DO droptlets for the streaming frontends right?
18:11:16 <wouter> olasd: well, I was thinking here, you know...
18:11:21 <tumbleweed> pollo: may as well
18:11:24 <paddatrapper> I certainly think we should default to infomaniak where possible
18:11:33 <paddatrapper> streaming frontends would not work there for example
18:11:53 <tumbleweed> would we want to spin up a debconf-specific jitsi, there?
18:11:56 <wouter> it's certainly also a good idea to spread streaming frontends across the globe
18:12:06 <paddatrapper> #agreed use infomaniak VMs for video team infrastructure where possible
18:12:23 <paddatrapper> tumbleweed: it would prevent having to mess with the streaming script, so maybe
18:12:27 <highvoltage> it would probably be nice to have jitsi close to voctomix if the machine can handle it
18:12:28 <paddatrapper> the NAT may be an issue though
18:12:39 <tumbleweed> the NAT doesn't seem to have been an issue, yet
18:12:40 <highvoltage> (jitsi and jibri, that is)
18:12:44 <tumbleweed> I was getting several gbps through it
18:12:57 <paddatrapper> tumbleweed: speed isn't the issue, webRTC and Jitsi are
18:13:02 <tumbleweed> I'd guess with some /etc/hosts munging, we can make that all behave
18:13:15 <paddatrapper> maybe, gave up on it last time
18:13:28 <tumbleweed> OK, so that's probably a next action here
18:13:32 <olasd> I'm sure people have managed to run jitsi on public clouds with nated public IPs before
18:13:34 <highvoltage> ah yes at AIMS we set up that one jitsi instance on a machine that also has a private IP but a public IP entirely natted to it and jitsi just couldn't do webrtc at all
18:13:36 <paddatrapper> may just need a proper TURN server
18:13:50 <tumbleweed> want to action me to setup a jitsi?
18:13:57 <paddatrapper> I'm happy to
18:14:03 <paddatrapper> set up enough of them at this point
18:14:14 <pollo> tumbleweed: if you do have time for that, please have a look and Ansible Galaxy and check if we can reuse a role there
18:14:21 <pollo> no point in writing tons of generic code
18:14:25 <paddatrapper> #action paddatrapper to setup a Jitsi VM and add to ansible
18:14:31 <wouter> yeah, I was about to say, might be a good idea to have an ansible something
18:14:37 <tumbleweed> they provide a debian package
18:14:42 <wouter> even so
18:14:45 <tumbleweed> so any existing ansible role may not have much value on top of that
18:14:46 <wouter> you still need configuration
18:14:50 <pollo> it's more complicated then apt install :s
18:14:53 <wouter> oh, that part :)
18:14:54 <wouter> right
18:15:19 <wouter> tumbleweed: do they provide a repository, or just a package?
18:15:24 <paddatrapper> wouter: repo
18:15:33 <pollo> you need to manage TLS certs, prosody, multiple services, etc.
18:15:36 * wouter makes a note to add it to extrepo, then :)
18:15:41 <tumbleweed> but yes, we should look at the ansible stuff
18:15:41 <pollo> and the debian packages are kinda crap
18:15:51 <pollo> they break often
18:16:48 <paddatrapper> Anything else on the video stack, or shall we move on to streaming setup?
18:16:49 <pollo> anyway, I've been burnt by Jitsi in the past and I'm happy others are in charge of it :p
18:17:01 <wouter> pollo: :D
18:17:14 <wouter> paddatrapper: I think we should move on?
18:17:15 <tumbleweed> it's good to get more people familiar with jitsi
18:17:23 <tumbleweed> I certainly learned a bit, adding the voip stuff
18:17:30 <paddatrapper> #topic Streaming Setup
18:17:47 <paddatrapper> #agreed streaming frontends still on digitalOcean
18:18:00 <paddatrapper> #action olasd to try minimize stream delay
18:18:21 <paddatrapper> don't think there is anything else?
18:18:25 <olasd> we've started butting heads on limitations of the nginx geoip module during MDCO so we need to figure a better solution for that
18:18:29 <wouter> don't think so either
18:18:33 <olasd> I think tumbleweed wrote $something
18:18:41 <wouter> olasd: can you expand on that? what's the issue?
18:18:53 <tumbleweed> I did
18:18:55 <tumbleweed> I need to finish it
18:19:08 <tumbleweed> stilll stuck on the maxmind license
18:19:16 <olasd> wouter: the geoip module shipped with nginx only supports the old database format, which maxmind has stopped providing free of charge
18:19:25 <wouter> oh, okay
18:19:28 <tumbleweed> and the new one has non-distributable terms
18:19:33 <tumbleweed> so we can't trivially ansible distributing it
18:19:39 <paddatrapper> #info the geoip module shipped with nginx only supports the old database format, which maxmind has stopped providing free of charge
18:19:44 <tumbleweed> (see the debian-legal thread)
18:19:47 <wouter> so, essentially, we should move to something not geoip I guess?
18:20:02 <olasd> tumbleweed: well it's not that different from the blackmagic situation
18:20:06 <tumbleweed> yeah
18:20:09 <wouter> (would be cool if we could have a database that knows about routing distances rather than country...)
18:20:31 <ivodd> well, we don't need to go over all the details in this meeting
18:20:43 <paddatrapper> tumbleweed: do you want an #action for this?
18:20:45 <wouter> well, that's called "anyrouting", I guess, but that would get us too far
18:20:47 <wouter> er
18:20:50 <wouter> anycast, I mean
18:21:00 <tumbleweed> paddatrapper: sure, give me an action to finish this
18:21:11 <olasd> I can also stare at it during sprint
18:21:14 <tumbleweed> I'll distribute the geoip db from people.debian.org, like olasd, probably :P
18:21:22 <paddatrapper> #action tumbleweed to find a solution to the geoip issue
18:21:33 <olasd> tumbleweed: or from the streaming backend
18:21:40 <olasd> (just wget it once)
18:21:44 <tumbleweed> yeah
18:21:46 <paddatrapper> #action Advice/training for directors (/talkmeisters)
18:21:58 <olasd> who's advice/training? :P
18:21:59 <wouter> paddatrapper: didn't you mean to topic that?
18:22:15 <paddatrapper> wouter: yes, that is the next point on the agenda
18:22:16 <wouter> (maybe undo this one first...)
18:22:26 <paddatrapper> #undo
18:22:26 <MeetBot> Removing item from minutes: <MeetBot.items.Action object at 0x157f850>
18:22:29 <paddatrapper> urg
18:22:34 <paddatrapper> #topic Advice/training for directors (/talkmeisters)
18:22:38 <wouter> :)
18:22:39 * paddatrapper needs coffee
18:22:39 <nattie> hello!
18:22:56 * pollo frowns at the idea at this hour
18:22:58 <pollo> :P
18:23:06 <paddatrapper> or sleep :P
18:23:18 <paddatrapper> at this point either would work
18:23:20 <wouter> didn't we say we wanted to decide on which recording stack we're going to have first, before thinking about training?
18:23:29 <pollo> we did do some work on this after the last meeting
18:23:40 <wouter> and since we're not quite decided yet...
18:23:44 <wouter> oh, okay
18:23:52 <paddatrapper> #link https://storm.debian.net/shared/iVvMB3RMXFtTen_jbtZ_FIh0-Ob54DaYvXvxaZx7_Ls
18:24:18 <paddatrapper> pollo: what still needs doing on it?
18:24:27 <paddatrapper> I assume technology specific stuff
18:24:41 <paddatrapper> #undo
18:24:41 <MeetBot> Removing item from minutes: <MeetBot.items.Link object at 0x1365210>
18:24:46 <paddatrapper> that link is for presenters
18:24:58 <paddatrapper> tumbleweed: do you have the directors, etc training link?
18:25:34 <pollo> ah, I confused the two then, I don't think we did work on that one yet for the reasons wouter mentionned
18:25:40 <paddatrapper> ok cool
18:25:54 <tumbleweed> I don't think we had a pad for training yet
18:26:09 <paddatrapper> #agreed will only start working on training for directors once video stack is finalized
18:26:11 <tumbleweed> offtopic, but: Issues created: https://salsa.debian.org/debconf-team/public/data/dc20-online/-/issues
18:26:17 <wouter> \o/
18:26:22 <paddatrapper> #topic Advice/training for presenters
18:26:27 <wouter> (and not offtopic)
18:26:33 <paddatrapper> #link https://storm.debian.net/shared/iVvMB3RMXFtTen_jbtZ_FIh0-Ob54DaYvXvxaZx7_Ls
18:27:13 <paddatrapper> does anything still need to be added there?
18:27:16 <wouter> I think that looks like a good idea
18:27:22 <pollo> we should start putting this in LaTeX and push it somewhere on salsa
18:27:30 <wouter> maybe limit to just one codec though
18:27:37 <wouter> ideally the codec we'll be using for live streaming
18:27:42 <paddatrapper> nattie: I seem to recall you and I offering to edit and compile that?
18:27:49 <tumbleweed> wouter: don't think the codec really matters
18:27:49 <pollo> or pandoc +md -> LaTeX
18:27:56 <nattie> paddatrapper: yeah, i think so
18:27:56 <tumbleweed> sphinx, like our other docs
18:28:04 <tumbleweed> wouter: it'll be going through voctomix
18:28:04 <paddatrapper> +1 for sphinx
18:28:07 <wouter> expecting vocto to transcode VP9 -> mp4 at live speeds might be expecting too much?
18:28:08 <pollo> ah, that's not a bad idead :0
18:28:24 <tumbleweed> wouter: that's not how vocto works
18:28:27 <wouter> or am I just being a pessimist here?
18:28:33 <tumbleweed> the ingest will decode to raw video, and give that to vocto
18:28:40 <wouter> oh, okay
18:28:42 <tumbleweed> the recording will encode to something
18:28:45 <tumbleweed> the stream will encode to something
18:28:48 <paddatrapper> #action paddatrapper to edit and compile presenter advice to video-team docs
18:28:56 <paddatrapper> #action nattie to edit and compile presenter advice to video-team docs
18:28:58 <wouter> so we run the ingest on a different VM from the voctocore one then?
18:29:13 <tumbleweed> maybe? maybe note
18:29:22 <tumbleweed> the ingest is almost free, it's just decoding video
18:29:41 <tumbleweed> and bandwdith into vocto
18:29:45 <paddatrapper> we should probably test and see
18:29:45 <wouter> yeah, okay, I just thought vocto would be transcoding, but if that's not the case, no worries then
18:29:47 <tumbleweed> probably makes sense to do it on the core VM for that reason
18:29:50 <wouter> and we have 10Gbit there, so yeah
18:30:19 <paddatrapper> #topic Any other business
18:30:32 <wouter> so, yeah
18:30:44 <wouter> zigo said that there is the possibility for block storage
18:30:47 <wouter> do we want to use that?
18:30:49 <pollo> it'll certainly be easier to have voctoweb run ingest shell commands if it's on the same host as the voctocore
18:31:02 <olasd> going back on the video stack topic: we need to make sure the core vms can be allocated enough disk space for 1/ having the pre-recorded videos stored; 2/ doing the voctocore recordings
18:31:06 <wouter> I can make SReview use block storage semi-directly, which could speed things up slightly
18:31:12 <CarlFK> wouter: vocto (like what is in the voc repo/package" is like an audio mixer - it has electroncic and a UI, but no mics or speaker hardware.  all that needs to be plugged in
18:31:29 <paddatrapper> #info there is the possiblity for block storage for the infomaniak VMs
18:31:31 <wouter> CarlFK: right
18:31:58 <wouter> essentially, I'm querying whether we want to run SReview on vittoria or at infomaniak
18:32:05 <wouter> and if the latter, whether we use block storage or NFS
18:32:20 <paddatrapper> #agreed we need to make sure the core vms can be allocated enough disk space for 1/ having the pre-recorded videos stored; 2/ doing the voctocore recordings
18:32:21 <wouter> I should note that I haven't used the block in anger yet, so
18:32:35 <wouter> block storage*
18:32:42 <wouter> what do people think?
18:32:56 * tumbleweed sees what storage options infomaniak has
18:33:04 <olasd> I don't know how to record to "block storage", whatever that is
18:33:12 <paddatrapper> can anything else use block storage directly? (aside from sreview)
18:33:13 <olasd> so we'll have to do a file transfer either way
18:33:27 <wouter> olasd: block storage is essentially Amazon S3 and lookalikes
18:33:29 <tumbleweed> they'll go up to 2TB
18:33:42 <ivodd> wouter: that sounds overly complex for little gain
18:33:49 <olasd> wouter: yeah, I don't know how to record to that; I don't think ffmpeg has a s3 output, nor gstreamer?
18:34:09 <ivodd> if we can get vms with enough disk space, that should be easier
18:34:17 <ivodd> and 2TB should be enough
18:34:19 <DLange> you can mount that as a filesystem (s3fs)
18:34:22 <wouter> ivodd: I don't think it is complex, but meh
18:34:23 <DLange> just sayin
18:34:39 <tumbleweed> DLange: sreview is quite I/O heavy
18:34:41 <ivodd> wouter: you wanted an opinion from someone else...
18:34:51 <wouter> also, modern SReview has sreview-copy which transparently copies into S3 if wanted
18:34:55 <olasd> DLange: I wouldn't want to chance live recordings on a fuse backend
18:34:59 <wouter> ivodd: sure
18:35:03 <CarlFK> pollo: can you point me to a wiki where I can make notes about playing videos?  (I hope I didn't miss this last week)
18:35:18 <DLange> I can just tell you it works better than NFS
18:35:24 <tumbleweed> CarlFK: https://salsa.debian.org/debconf-team/public/data/dc20-online/-/issues/3
18:35:27 <DLange> so if only these two are your choices...
18:35:32 <olasd> DLange: that's a low bar to pass
18:35:38 <DLange> olasd: full ack
18:35:38 <CarlFK> tumbleweed: thanks
18:36:03 <phls> will content team ask  presenters if they want make live streaming or send recorded talk?
18:36:20 <tumbleweed> phls: I think they'll strongly encourage them to record
18:36:34 <wouter> okay, was just idly wondering, but I guess if it makes the streaming side of things more complex, it's probably not worth it
18:37:00 <tumbleweed> wouter: hrm, how does it relate to streaming?
18:37:13 <wouter> tumbleweed: er, I meant the recording side of things
18:37:15 <olasd> tumbleweed: s/streaming/recording/
18:37:17 <olasd> right
18:37:25 <paddatrapper> #agreed we won't use block storage for recording, as it makes things more complex
18:37:26 <CarlFK> he wants to plug the tape recorder into the line out of a powered speaker :D
18:37:45 <wouter> CarlFK: well, it is how FOSDEM does things
18:37:51 <wouter> (the live stream is recorded)
18:37:58 <CarlFK> see!
18:37:59 <wouter> and yes, that's crazy and has shitty downsides
18:38:09 <paddatrapper> Any other business?
18:38:24 <wouter> still want to know whether to run sreview on vittoria or at infomaniak
18:38:47 <wouter> even if we don't do the block storage, it might still be a good idea (or not) to run SReview at infomaniak at one of the VMs there
18:38:53 <paddatrapper> probably infomaniak would be good?
18:39:00 <tumbleweed> wouter: when do you want to start setting up sreview?
18:39:03 <paddatrapper> makes file transfer easy
18:39:14 <tumbleweed> paddatrapper: hrm?
18:39:14 <olasd> we'll want to archive the recordings on vittoria, the infomaniak offer is time-limited
18:39:17 <wouter> tumbleweed: eh, haven't thought of that yet :)
18:39:26 <paddatrapper> tumbleweed: s/easy/fast
18:39:37 <wouter> olasd: yeah, sure, but I'm mostly concerned about massive file transfers during the conference
18:40:07 <wouter> tumbleweed: I could probably start off slowly if the VMs at infomaniak are going to stick around until debconf
18:40:24 <tumbleweed> zigo didn't want us to consume vast VMs for months
18:40:30 <wouter> (on a side note, I could also fix the bugs in ansible around SReview that I have been sitting on since dc19...)
18:40:43 <tumbleweed> so it'd probably make sense to delay creating the big 2TB VM for a while (unless he's OK with that)
18:41:04 <wouter> I'd think we'd want that one to be an NFS server and nothing else?
18:41:10 <tumbleweed> I guess all the sreview stuff is ansibled enough that we don't need to be worrying abuot this right now
18:41:21 <wouter> you'd guess slightly wrongly ;)
18:41:27 <tumbleweed> heh
18:41:28 <olasd> 2TB is also probably more than we need; are we splicing the original recordings or are we recording our playback?
18:41:31 <wouter> most of it is ansibled fine, but some of it is slightly buggy
18:42:01 <wouter> it would be cool if I could work on this a bit more while I have VMs that are going to stay around for more than a debconf
18:42:01 <tumbleweed> olasd: presumably we're recording our playback, for our sanity?
18:42:20 <olasd> tumbleweed: I don't know, which is why I'm asking ;)
18:42:20 <paddatrapper> Also splicing isn't well supported
18:42:56 <olasd> anyway, nothing further that *needs* discussing now from me
18:43:03 <wouter> because usually I go "don't have the time to fix this now, I'll do it manually", and then things like https://salsa.debian.org/debconf-video-team/ansible/-/issues/40 happen...
18:43:26 <wouter> I think we should be recording our playback
18:43:41 <paddatrapper> #agreed we will record our own playback
18:43:43 <ivodd> it would be nice if you could use the source instead
18:43:46 <wouter> mostly because SReview assumes an uninterrupted timeline
18:43:52 <tumbleweed> wouter: they go up to 32 core. would you just want a single VM for sreview then?
18:43:54 <ivodd> that way, the video could be released immediately when the talk ends
18:44:05 <tumbleweed> ivodd: then you lose Q&A
18:44:08 <ivodd> but that's "nice to have", not a requirement
18:44:11 <wouter> tumbleweed: wow, yeah, that's more than enough
18:44:17 <ivodd> tumbleweed: I'm talking for talks where there is no live q&a
18:44:31 <wouter> ivodd: mmm, good point
18:44:32 <tumbleweed> ivodd: sure, we could publish those directly
18:44:42 <tumbleweed> probably bypassing sreview entirely
18:44:49 <ivodd> maybe sreview can do it
18:44:58 <ivodd> (if I can find the energy to look at it again)
18:45:01 <wouter> it shouldn't be too hard to make it bypass the review cycle
18:45:24 <pollo> wouter: zigo did ask us to try to use as few resources as possible though, as a 32 cores VM means racking a server for them or something
18:45:51 <wouter> pollo: I'm not going to actually use the cores, but I don't think he's going to kill me if I end up running ansible on it a few times?
18:45:57 <wouter> I'll double-check with him to be sure
18:46:03 <wouter> zigo: ^^ ;-)
18:46:06 <wouter> (there, done ;-P)
18:46:07 <tumbleweed> yeah, let's have that discussion with him outside this meeting
18:46:24 <paddatrapper> #action wouter to talk to zigo about VM resource use
18:46:34 <paddatrapper> #topic Upcoming meetings
18:46:44 <wouter> can you also #action me about bypassing the review for prerecorded talks?
18:46:50 <paddatrapper> #undo
18:46:50 <MeetBot> Removing item from minutes: <MeetBot.items.Topic object at 0x140ca10>
18:46:53 <ivodd> wouter: we don't want to bypass the review
18:47:00 <ivodd> we want it to be (slightly) different
18:47:05 <wouter> well, that
18:47:10 <tumbleweed> bypass recording, essentially
18:47:11 <paddatrapper> #action wouter to work on review for prerecorded talks
18:47:17 <wouter> thx
18:47:20 <paddatrapper> #topic Upcoming meetings
18:47:23 <paddatrapper> Next week Thursday @ 18:00 UTC?
18:47:28 <nattie> sure
18:47:42 <tumbleweed> yeah
18:47:45 <paddatrapper> #agreed Next IRC meeting - Thursday 9 July @ 18:00 UTC
18:47:54 <wouter> wfm, mostly
18:48:08 <paddatrapper> #info Online sprint is 10-12 July
18:48:24 <tumbleweed> it's a long weekend here, this weekend ('murica day, basically)
18:48:25 <ivodd> according to olasd, also 13/14 ;)
18:48:29 <tumbleweed> so I'll be hacking
18:48:38 <olasd> ivodd: t-t-t
18:48:44 <wouter> not sure yet whether I'll have a lot of time, but I can see
18:48:49 <olasd> I said /overflow/
18:49:08 <paddatrapper> #info can tentatively aim for some video test runs on the weekend of 17-19 July
18:49:25 <paddatrapper> #endmeeting