19:45:35 <sumpfralle1> #startmeeting
19:45:35 <MeetBot> Meeting started Wed Jan 29 19:45:35 2020 UTC.  The chair is sumpfralle1. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:45:35 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:45:48 <sumpfralle1> #chair sumpfralle1 TheSnide h01ger
19:45:48 <MeetBot> Current chairs: TheSnide h01ger sumpfralle1
19:45:55 <sumpfralle1> #topic munin-node-win32
19:46:09 <sumpfralle1> Yes, indeed - it is alive: https://github.com/munin-monitoring/munin-node-win32/issues/47#issuecomment-579250028
19:46:25 <sumpfralle1> TheSnide: do you have an idea, how we can handle these contributions?
19:46:57 <sumpfralle1> I thought, the repository was silent for long - but indeed there was a merge of a pull request in last February.
20:06:06 <TheSnide> to be fair, i don't even have an environement where I can test things
20:06:56 <TheSnide> .. and i wanted to migrate to munin-c for win32 also, but this didn't happen. And if there's interest to revive munin-node-win32, I won't obviously oppose it
20:07:20 <TheSnide> ... now, your question is indeed a very interesting one.
20:09:01 <sumpfralle1> I tried to notify the existing munin-node-win32 team members: https://github.com/munin-monitoring/munin-node-win32/issues/47#issuecomment-579250028
20:09:12 <sumpfralle1> But maybe there is a better way to reach them?
20:09:29 <sumpfralle1> (they would be good candidates for accepting changes or even new team members)
20:10:42 <TheSnide> well, those team members are long gone.
20:11:16 <TheSnide> i mean, I didn't see them since about 3-4 years
20:12:07 <TheSnide> _the_ way to move forward would really to add new contributors.
20:12:42 <sumpfralle1> The last commit by jccston was here: https://github.com/munin-monitoring/munin-node-win32/commit/94c93432a78d0124a237729bdb5fc1af2ddd9047 (February)
20:12:57 <TheSnide> but even with the issue that you mentionned, I don't have _any_ expertise in reviewing any code.
20:13:04 <sumpfralle1> but anyway: if we do not have ways to contact them, then we have to go without their voice.
20:13:15 <TheSnide> I would simply not know if it's better of worse ;)
20:13:18 <sumpfralle1> :)
20:13:48 <sumpfralle1> same to be - I just a fairly outdated (>10 years) memory of windows packaging.
20:14:11 <TheSnide> the win32 node was moved over to us, in order to centralize a distributed patchwork.
20:14:33 <TheSnide> but, noone did properly handle it.
20:15:04 <TheSnide> that said, it was better than nothing. as it automatically attracted each and every possible person with a interest in it.
20:15:11 <TheSnide> the "github network effect"
20:15:12 <sumpfralle1> yes
20:15:50 <TheSnide> So, I'll a little ashamed of the state of it. but unfortunately, there's very little _i_ can do.
20:16:32 <TheSnide> So, mostly any idea you'd have, would be fine by me
20:18:35 <sumpfralle1> I could take a long look at the previous changes and would propose to add the contributor to the team (you would need to do this, I guess), if they look good to me. This does not solve the potential issue of "overtaking a project after submitting innocent improvements". But I do not think, that munin-node-win32 is a fruitful target for such exploitve activity. Thus I would restrain my paranoia
20:18:36 <sumpfralle1> here.
20:19:49 <TheSnide> i'm less concerned about "overtaking the project" than "inserting a backdoor" ;)
20:21:14 <sumpfralle1> Yes, that's what I meant, too.
20:21:33 <TheSnide> At least in munin & munin-c i'm not an expert, but I can understand most of the things that are in the PR
20:21:50 <TheSnide> (which doesn't mean I'm 100% foolproof...)
20:23:07 <sumpfralle1> Being human is acceptable in this project, I guess :)
20:23:24 <sumpfralle1> Do you agree to my proposal above or would you prefer a different approach?
20:26:22 <TheSnide> agreed
20:27:45 <sumpfralle1> Good - so I will take a close look and we hope for a vivid future of munin-node-win32 ...
20:28:01 <sumpfralle1> #topic everything else
20:28:13 * TheSnide wonders if it might be a good time for a new 2.999 release
20:28:33 <sumpfralle1> Do you have other topics?
20:29:24 <bcg> munin for epel8 (rhel8) is now on epel's testing repository.
20:29:34 <TheSnide> _o/
20:30:05 <TheSnide> anything special in that one ? or is it just a port to rhel8?
20:30:48 <bcg> nothing special. and it's based on 2.0 branch, which I didn't want to do.
20:31:48 <bcg> It just took some time as I had to wait for some dependencies to be available.
20:32:23 <sumpfralle1> how long will epel8 be supported? (just for my curiosity)
20:33:01 <bcg> epel doesn't have any specific lifetime.
20:33:07 <TheSnide> a while I guess.. at it's the new one, no?
20:34:22 <bcg> epel faq says: "The plan is for EPEL packages to get updates as long as the corresponding RHEL release is supported. That is 10 years after the initial release according to the current errata support policy for 5, 6, and 7 releases."
20:34:36 <bcg> but no, I won't support munin 2 for next 10 years.
20:34:41 <TheSnide> ;)
20:34:59 <TheSnide> well, i guess the amount of support on munin is rather on the low side
20:35:05 <TheSnide> (i hope)
20:35:32 <sumpfralle1> At least regarding security issues, I guess.
20:35:41 <bcg> Basically none at the moment.
20:40:50 <bcg> if you're interested to see my crontab -> systemd timer+tmpfiles work, or any other rhel/fedora-stuff, see https://src.fedoraproject.org/rpms/munin
20:41:17 <TheSnide> "systemd timer+tmpfiles work" \o/
20:42:14 <TheSnide> https://src.fedoraproject.org/rpms/munin/blob/master/f/21b3d860c17d7997d64267963f91ed75ca8a3e03.patch
20:46:58 <sumpfralle1> probably this one instead: https://src.fedoraproject.org/rpms/munin/c/8793e82c1ebfb77d43686050e0650e6f62bfc13a
20:49:30 <TheSnide> oh, yeah. the 2 were unrelated. Was just wondering about why the patch.
20:49:41 <TheSnide> ... coming to think that we should end the meeting ;)
20:50:05 <TheSnide> (and babble outside it)
20:50:38 <TheSnide> #endmeeting