18:30:52 <sumpfralle> #startmeeting
18:30:52 <MeetBot> Meeting started Wed Apr 29 18:30:52 2020 UTC.  The chair is sumpfralle. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:52 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:31:07 <sumpfralle> It is Wednesday evening again: time for our weekly IRC meeting ...
18:31:26 <sumpfralle> If you want to share or discuss something: this is your time.
18:38:41 <sumpfralle> h01ger: I managed to postpone the Debian packaging update for too long :( - Tomorrow it shall be ...
18:39:33 <sumpfralle> #topic Plugins in main repository / Debian packages
18:40:10 <sumpfralle> Recently a user asked in a plugin for the inclusion of a plugin from contrib in the main repository (in order to get this plugin via the Debian package).
18:40:55 <sumpfralle> I have the slight feeling, that we discussed a similar topic in the last year, but I cannot remember and I failed to find it in the meetbot archive (or I used the wrong keywords).
18:41:18 <sumpfralle> Do you remember such a discussion or anything in the direction of a "policy"?
18:42:19 <sumpfralle> (please for now ignore, that the coupling of core repository and Debian package is not strictly required; this is a separate topic)
18:43:10 <TheSnide> hi
18:43:31 <sumpfralle> hello!
18:45:56 <TheSnide> about inclusion in main git, i'd say "it's going to be complex"
18:47:03 <TheSnide> My rule-of-thumb is "allow it only if one of the core team does use it actively". Otherwise we'll have effectively-unsupported plugins.
18:47:17 <TheSnide> and, I don't really want to increase that.
18:48:13 <TheSnide> That said, a _very_ good idea would be to provide a contrib-to-deb tool. Very much like "dh-make-perl".
18:48:57 <TheSnide> https://manpages.debian.org/buster/dh-make-perl/dh-make-perl.1p.en.html
18:49:34 <sumpfralle> Nice idea.
18:49:57 <sumpfralle> But I guess, it does not solve the problem of "someone else should maintain and update it" :)
18:50:39 <sumpfralle> I can also imagine, that we start packaging some plugins from contrib for Debian. But I think, this is a separate discussion.
18:51:26 <sumpfralle> Thus for the main repository (of munin itself): I undestand your approach, that you want to see a forseable maintainance over the next years.
18:51:45 <sumpfralle> (just summarizing - not perfect)
18:52:40 <sumpfralle> I struggled to phrase a good description for the distinction between core and contrib in a few bug reports.
18:53:18 <sumpfralle> For now I went along the line of "to be useful on almost every system".
18:53:45 <sumpfralle> (this would obviously exclude half of the plugins in core)
18:55:29 <sumpfralle> I understand that the current distinction of plugins between core and contrib is definitly arbitrary (based on the time of being introduced, and so on ...). Thus it reflects the timeline of the project and not the relevance/usefulness of the plugin.
18:56:12 <sumpfralle> I do not see this as a real problem. But I guess, we could define some guidelines at least for *new* plugins.
18:57:21 <sumpfralle> TheSnide: feel free to stop or redirect my train of thoughts ...
18:59:38 <TheSnide> main is "core supported". contrib is "community supported"
18:59:59 <TheSnide> which usually means that:
19:00:36 <TheSnide> main has a chance of someone looking at it, whereas community is best fixed by oneself, and given back.
19:01:31 <TheSnide> I would admit that we are not very good in fixing bugs in main. So, in contrib it's worse.
19:02:20 <TheSnide> so, the natural way of being able to fix bugs is to have limited set of those. And that they are used by the maintainers.
19:02:34 <TheSnide> which naturally flows to "most used plugins"
19:03:52 <sumpfralle> And it leads to a state, where this statement does not really match with the majority of plugins in main, I guess :)
19:04:01 <sumpfralle> But i can live with such a description.
19:04:08 <TheSnide> I would really ask the "real" reason behind the will to move a plugin into core. Usually it is because "then it is in the debian package". And that usually means that "it is more maintained". which then "then I can use it in production".
19:04:41 <sumpfralle> Yes, in this case it was definitly about the Debian package. But this is a separate issue, I think.
19:05:04 <TheSnide> and, i cannot change the past. As I really am keen on "not breaking things that aren't borken". So kicking out lesser used plugins of main doesn't seem a bright move.
19:05:06 * sumpfralle wants to have this distinction mainly for himself
19:05:41 <sumpfralle> Yes, I know. And I do want to encourage that.
19:06:02 <TheSnide> So, as long as a plugin has no critical bugs, it stays in main. Even if noone has any clue on how to maintain it.
19:06:13 <sumpfralle> I am just looking for some description, how we decide for *new* plugins. The existing ones are just history.
19:07:01 <sumpfralle> Correcting my typing above: "Yes, I know. And I do want to encourage that." -> "Yes, I know. And I do not want to encourage such removal."
19:07:02 <TheSnide> But.. on the other side, I'd rather limit what enters. As any new code is buggy. at least the plugins that are in have succeded the test of time.
19:07:07 <TheSnide> :)
19:07:43 <sumpfralle> Yes, I share this "limiting" feeling.
19:08:02 <TheSnide> So, if you think you can maintain a plugin for the forseable future, you can include it .
19:08:23 <TheSnide> but, to be honest, each and every new plugin I wrote, never landed in main.
19:08:31 <sumpfralle> :)
19:08:42 <sumpfralle> same for me - I usually move them to contrib
19:08:42 <TheSnide> So, I do apply that rule even to myself.
19:09:38 <TheSnide> But a dh-make-muninplugin would be nice. A I don't think it might be that complex to create.
19:09:47 <TheSnide> And* I
19:10:31 <TheSnide> It would even enable a correct versionning of "Suggest" and "Depends"
19:11:01 <TheSnide> ... Also, I would _not_ mind to host those debianized plugins via a APT repository.
19:12:27 <TheSnide> That said, I don't think it would be a very good idea for our users to depend on it. I mean, since we don't have a good quality gate for contrib, you might end up having a huge security hole if you update automaticallly.
19:12:51 <TheSnide> IMHO a plugin, specially a 3rd-party one, shall not be updated automatically. Ever.
19:14:52 <sumpfralle> Yes, hosting such packages is not a good idea, I am afraid :)
19:16:12 <sumpfralle> Regarding the criteria for new plugins entering main: do you think, that something like "should be useful on most systems" would be too limiting?
19:17:19 <sumpfralle> but in reality we did not admit any new plugins in the last four years, or?
19:20:42 <sumpfralle> I have the feeling, that I am expressing myself in a slightly confusing way, today ...
19:25:17 <sumpfralle> Trying to summarize it:
19:25:19 <sumpfralle> * criterion for new plugins: it is reasonable to assume, that they are maintained in the forseeable future (e.g. by a munin developer)
19:25:21 <sumpfralle> * we do not want to remove existing plugins from main (not just based on them not meeting our current criteria)
19:25:22 <sumpfralle> correct?
19:27:41 <TheSnide> yep
19:28:57 <travis-ci> munin-monitoring/munin (master - 4901f3c : Lars Kruse): The build has errored.
19:28:57 <travis-ci> Build details: https://travis-ci.org/munin-monitoring/munin/builds/681163567
19:33:44 <sumpfralle> OK - I will find a good place for this piece of information somewhere in ...
19:34:56 <sumpfralle> Let us discuss the (proper) Debian packaging and possible self-made packaging next week?
19:35:34 <sumpfralle> With "proper" I meant plugins that are distributed by Debian (not as a deb package).
19:36:47 <sumpfralle> (h01ger surely will want to share his thoughts on this matter, too)
19:58:47 <travis-ci> munin-monitoring/munin (master - 28d781b : Lars Kruse): The build passed.
19:58:47 <travis-ci> Build details: https://travis-ci.org/munin-monitoring/munin/builds/681173835
20:03:38 <sumpfralle> btw: I just merged 2.0.60 into master. Maybe it is time for a release? :)
21:13:09 <TheSnide> k
21:43:50 <sumpfralle> #endmeeting