18:35:30 <sumpfralle1> #startmeeting
18:35:30 <MeetBot> Meeting started Wed Aug 21 18:35:30 2019 UTC.  The chair is sumpfralle1. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:35:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:35:47 <sumpfralle1> It is Wednesday again - time for the weekly IRC meeting ...
18:36:11 <sumpfralle1> Starting with the usual topic: "what happened in the last week of munin?"
18:39:03 <bcg> EPEL8 is now open, and I don't want to package Munin 2 there. I'll do Munin 3 instead, when I have time.
18:42:00 <sumpfralle1> bcg: I think, this is quite a brave move at the moment. But I have no intention to try to stop you :)
18:42:05 <sumpfralle1> What is the time until the freeze?
18:42:23 <sumpfralle1> #topic munin 3 for EPEL
18:43:37 <sumpfralle1> #chair TheSnide h01ger bcg
18:43:37 <MeetBot> Current chairs: TheSnide bcg h01ger sumpfralle1
18:45:26 <bcg> Freeze? There's no freeze in epel.
18:46:23 <bcg> EPEL7 will stay in Munin 2, as auto-upgrade 2->3 is too much work.
18:48:11 <sumpfralle1> I meant the time of the epel8 release. In Debian they call it "freeze" when the last upgrade of the upstream version should be packeged. Afterwards only small fixes are allowed.
18:49:50 <bcg> Epel is rolling release, so next 5-8 years...
18:50:33 <bcg> I could package munin2 and munin3 as separate packages there, but again that's extra work.
18:51:31 <sumpfralle1> I understand. OK - so it sounds reasonable. Nice!
18:52:36 <sumpfralle1> I think, the "limits" (alarming) are not handled in munin 3 at the moment. The rest should be fine, I guess.
18:54:02 <bcg> For my own munin setups limits are important, so I might end up running munin2 master and munin3 clients.
18:54:58 <sumpfralle1> That should work great.
18:56:59 <bcg> Or multi-master, munin2 for limits only and munin3 for web interface?
18:57:28 <bcg> Or I just keep nagging here until limits are implemented in munin3.
18:58:18 <sumpfralle1> That is the way to go :)
19:06:52 <sumpfralle1> #endmeeting