19:29:15 <sumpfralle> #startmeeting
19:29:16 <MeetBot> Meeting started Wed Apr 18 19:29:15 2018 UTC.  The chair is sumpfralle. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:29:16 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:29:35 <sumpfralle> #chair TheSnide dipohl h01ger be0rn chteuchteu
19:29:35 <MeetBot> Current chairs: TheSnide be0rn chteuchteu dipohl h01ger sumpfralle
19:29:55 <sumpfralle> welcome to the weekly munin meeting :)
19:30:20 <dipohl> welcome back sumpfralle :)
19:31:18 <sumpfralle> thank you!
19:31:24 <sumpfralle> #topic review last meeting
19:31:37 <sumpfralle> http://meetbot.debian.net/munin/2018/munin.2018-04-04-19.30.html
19:32:34 <sumpfralle> There were two action items: (1) myself registers the munin website at web.archive.org and (2) TheSnide recovers a few removed guide pages for munin-2.0
19:32:56 <sumpfralle> (1): I failed to do this - and I am almost convinced now, that there is no need to "subscribe" there?
19:33:05 <sumpfralle> any other opinions on that matter?
19:33:53 <dipohl> for what purpose should we archive the old trac wiki?
19:34:25 <dipohl> it's nearly empty compared to the state of 2013..
19:34:38 <sumpfralle> it was part of the discussion in the last meeting. If I remember correctly, we confused each other a bit with archive/backup/dump/export ...
19:34:49 <sumpfralle> yes, I think, we can omit that topic
19:34:54 <dipohl> +1
19:35:42 <sumpfralle> regarding the guide pages regarding munin-2.0: I did not take a close look - are they still lost in the git history?
19:36:41 * sumpfralle looks at the git history now
19:37:34 <dipohl> I looked in the Guide and there is no info about munin-graph and munin-html
19:37:35 <dipohl> http://guide.munin-monitoring.org/en/latest/master/index.html
19:38:31 <dipohl> compare it with the stable 2.0 Guide: http://guide.munin-monitoring.org/en/stable-2.0/master/index.html#components
19:38:46 <sumpfralle> indeed!
19:39:01 <sumpfralle> thus they were only added to the stable repository. Now I get it ...
19:39:06 <sumpfralle> I can move them over.
19:39:21 <dipohl> I don't thinkt they were added there
19:39:34 <dipohl> we only fed the master repo
19:39:51 <dipohl> so someone deleted the pages I suppose
19:40:10 <dipohl> we can check with "blame" in git
19:40:11 <sumpfralle> hm - but I took a quick look at the doc/ history in master and saw only the two of use adding commits in the last six month
19:40:32 <dipohl> master branch was devel before
19:40:39 <dipohl> and we fed to devel before
19:41:04 <sumpfralle> ah - here it is: 466ac02e46c389fa78da6cbe347a4c70f4b7255a
19:41:08 <sumpfralle> removed in 2015 by ssm
19:41:41 <sumpfralle> should we just revert this one - or do you suspect other missing details?
19:41:49 <dipohl> I don't know
19:42:14 <dipohl> I think it is worth to check ssm activities at the time
19:42:55 <dipohl> I thought TheSnide claimed that task in the last meeting
19:43:14 <sumpfralle> ok - so we leave it with him, until he complains :)
19:43:32 <sumpfralle> #action TheSnide will recover the few removed munin-2.0-pages of the munin-guide
19:43:49 <sumpfralle> #topic documentation
19:43:56 <dipohl> I hope that it will be done carefully..
19:44:15 <sumpfralle> of course!
19:44:29 <dipohl> it is not funny to invest such an amount of time and work (as I did in the last years) and see vanishing the fruits..
19:44:29 <sumpfralle> recently we talked about man pages and the doc directory
19:44:39 <sumpfralle> I understand
19:45:12 <sumpfralle> man/sphinx: I noticed that the manpages for the Debian package are generated from the doc directory.
19:45:23 <sumpfralle> by "make -C doc man" - just using sphinx
19:45:31 <sumpfralle> thus the magic is resolved?
19:46:06 <dipohl> so they are built from the guides pages already?
19:46:19 <sumpfralle> yes
19:46:26 <sumpfralle> just how it should be :)
19:46:46 <sumpfralle> at that moment I realized, that a bit of documentation of the build system would be nice
19:47:02 <dipohl> hmm, then we would have to care for this parts in the stable-2.0 repo..
19:47:17 <dipohl> a task that I was not aware of since now..
19:47:31 <sumpfralle> #action sumpfralle will add build system details to the development documentation of the guide (in case it is missing)
19:47:57 <dipohl> many thanks in advance for that!! :-)
19:48:14 <sumpfralle> indeed there are no manpages in the Debian package for 2.0.x
19:48:42 <sumpfralle> thus the bits are probably missing from stable-2.0 (expected - since we care only about the doc in master)
19:49:01 <dipohl> what the f..
19:49:16 <sumpfralle> ?
19:49:49 <sumpfralle> or: they are just not built from that directory (this would be a thing for the Debian package)
19:49:50 <dipohl> I didn't expect such a mess..
19:50:05 <sumpfralle> probably I got it wrong
19:50:16 <sumpfralle> there is indeed the doc directory in stable-2.0
19:50:21 <dipohl> I see man pages in epel munin
19:50:33 <sumpfralle> but the Debian package just did not use them - that's it
19:50:34 <dipohl> but they are different from the guides man pages
19:50:48 <sumpfralle> different from the old ones?
19:50:56 <sumpfralle> ("old" -> "stable-2.0" branch)
19:51:18 <dipohl> I didn't check the new Munin version
19:51:51 <dipohl> I am talking about the last epel package 2.0.33 if I see it right
19:52:42 <dipohl> I thought the man pages were built from "normal" files in the repo there not from the Guide..
19:53:25 <sumpfralle> at least the Debian packaging uses just the source tarball of the release
19:53:29 <dipohl> TheSnide, h01ger: are you here?
19:53:35 <sumpfralle> thus (for 2.0.x): the branch "stable-2.0"
19:54:24 <sumpfralle> I think, it is fine like that - maybe a bit outdated compared to the master branch - but I do not think, that we should focus on that.
19:54:36 <dipohl> +1
19:54:47 <sumpfralle> anyway: I will take a look at the man pages for the current munin package in Debian. h01ger will probably like that ...
19:55:05 <dipohl> but there should be man pages also in the debian package of stable 2.0
19:55:18 <sumpfralle> #action sumpfralle will include manpages in the current (2.0.x) Debian package
19:55:27 <dipohl> that's the only point I have..
19:55:32 <dipohl> thanks again!
19:56:09 <sumpfralle> we will see, if my next week will be more productive than the last one :)
19:56:20 <dipohl> I think it is ok to maintain the man pages for 2.0 in other files
19:56:51 <dipohl> we should start the /new/ method with 2.999
19:57:13 <sumpfralle> they are there in the doc directory - ready to be used (at least I assume that)
19:57:53 <sumpfralle> make -C doc man
19:57:57 <sumpfralle> writing... munin-async.1 { } munin-asyncd.1 { } munin-cgi-graph.1 { } munin-cgi-html.1 { } munin-check.1 { } munin-cron.1 { } munin-graph.1 { } munin-html.1 { } munin-limits.1 { } munin-node.1 { } munin-run.1 { } munin-update.1 { } munin.conf.5 { } munin-node.conf.5
19:58:06 <sumpfralle> this should be sufficient
19:58:15 <sumpfralle> (in stable-2.0)
19:58:27 <dipohl> and we need to clearly address outdated features, so care for multi-version in the new method
19:58:40 <sumpfralle> yes
19:58:45 <dipohl> as in the guide we want to explain both versions
19:58:48 <sumpfralle> do we already know how we can tag them?
19:59:08 <dipohl> but the man pages should contain only valid 2.999 info
19:59:29 <dipohl> tagging: no
19:59:38 <dipohl> nobody answered to your call on the ML
20:00:11 <sumpfralle> I repeated it now - we will see ...
20:00:35 <sumpfralle> "but the man pages should contain only valid 2.999 info" - this will be tricky
20:00:52 <sumpfralle> probably we will need to live with textual markup ("only 3.x" ...)
20:01:15 <dipohl> perhaps we can integrate sort of exclusion marks
20:01:24 <sumpfralle> (I am not a sphinx expert - just guessing)
20:02:02 <dipohl> or add some awk magic to the man page build
20:03:15 <dipohl> the "only 3.x" will not be the problem, when we only use the new method for 2.999/3.x
20:03:31 <dipohl> but to throw out outdated infos from stable 2.0
20:03:42 <dipohl> in the man pages for 2.999
20:04:49 <dipohl> or we maintain 2 separate pages in the guide only for this content (man pages)
20:05:08 <sumpfralle> with "only 3.0" markers, I meant markers for 3.0 and 2.0 - I could live with that, if sphinx does not offer something out of the box
20:05:13 <dipohl> we cannot do this for all the content, but only for the man pages will be possilbel
20:05:23 <dipohl> possible
20:05:50 <sumpfralle> personally I do not think, it is worth the effort - adding hints "only 2.0" and "only 3.0" would be sufficient for me
20:06:20 <dipohl> do you know of other software that has multi-version man pages? I don't
20:06:37 <sumpfralle> I will take a look, if sphinx offers a feature like that
20:06:39 <dipohl> And I wouldn't like it
20:06:51 <sumpfralle> ressources, ressources :)
20:07:13 <dipohl> we are talking about 4 or 5 pages if I see it right
20:08:02 <dipohl> I would prefer the sphinx / make -C doc man magic
20:08:03 <sumpfralle> I have no real opinion - and I could live with any option
20:08:24 <dipohl> but if not possible I vote for separate pages
20:08:28 <dipohl> for both versions
20:09:30 <dipohl> I can live with a multi-version guide and see also advantages as we show the users the differences between the 2 versions, so the progress of the new version
20:09:48 <dipohl> but a man page should address the version that I installed
20:10:04 <dipohl> and not outdated info
20:10:12 <sumpfralle> we can have this anyway: the files are separate in the two branches
20:10:36 <sumpfralle> thus we do not apply the "multi-version" policy to the manpage source files, right?
20:11:18 <sumpfralle> that is: everything below doc/reference
20:11:33 <dipohl> Let's see if we find sphinx / make doc magic to break down fitting man pages for both versions
20:11:50 <dipohl> that would be the best in my view
20:12:00 <sumpfralle> but remember: manpages for 2.0.x will always be built from the stable-2.0 branch, anyway
20:12:11 <dipohl> as I said before
20:12:19 <sumpfralle> (at least it is the Debian way of generating manpages from the source tarball)
20:12:23 <dipohl> let us build the man pages for stable 2.0 in the old way
20:12:37 <sumpfralle> there is no old way - I think, we have a misunderstanding here
20:12:43 <sumpfralle> there is only the sphinx way
20:12:48 <sumpfralle> I am not aware of another one
20:12:50 <dipohl> so not from the guide but from separate files in the source tarball
20:13:18 <sumpfralle> maybe I used improper wording: I always refered to the "doc/" directory
20:13:34 <sumpfralle> there are the manpage sources below doc/reference - see doc/conf.py
20:13:44 <sumpfralle> for master as well as for stable-2.0
20:13:55 <dipohl> https://github.com/munin-monitoring/munin/tree/stable-2.0/master/doc
20:14:11 <dipohl> ^that is not the guide!
20:14:27 <sumpfralle> thus it was just my confusing wording - sorry
20:15:08 <dipohl> so the new method to fetch the man pages from the guide is not implented yet also for the master branch?
20:16:14 <sumpfralle> let me rephrase it: we can run "make -C doc man" both in master and in stable-2.0. This was always possible. The resulting files are currently not used by the Debian package. I will take a look at that.
20:16:22 <sumpfralle> From my point of view, there is nothing to be done or changed?
20:16:38 <dipohl> https://github.com/munin-monitoring/munin/tree/stable-2.0/node/doc
20:17:00 <sumpfralle> this could be added, as well
20:17:23 <dipohl> there should be another man page for the node: "munindoc"
20:17:34 <dipohl> which seems to be missing at the time
20:17:47 <sumpfralle> and there is master/doc, too
20:19:39 <sumpfralle> the munindoc' manpage could be generated via perldoc - indeed
20:19:59 <sumpfralle> this should cover it all: doc/reference, node/doc, master/doc, node/bin/munindoc
20:20:27 <dipohl> build from doc/reference is the /new/ method
20:20:30 <sumpfralle> the Makefile refers to all of them, I think
20:20:34 <sumpfralle> yes
20:20:59 <dipohl> let us stop and pick up this thread again when you have documented the build process and h01ger and TheSnide are also on board, ok?
20:21:04 <sumpfralle> yes
20:22:21 <sumpfralle> thus let us close this meeting?
20:23:39 <dipohl> one point left on my side
20:23:49 <dipohl> #topic vetted plugins
20:23:52 <dipohl> http://guide.munin-monitoring.org/en/latest/develop/plugins/requirements-vetted.html
20:24:02 <dipohl> did you see this?
20:24:36 <sumpfralle> yes, I was happy to see another one disappearing :)
20:25:38 <dipohl> I would highly appreciate if you add your /rules/ from contrib therein
20:26:21 <sumpfralle> it would fit there - but I am not sure, if we should remove them from contrib/plugins/README in this case? I would not like to care for two copies?
20:27:19 <dipohl> I think of only the subject "plugin code" related issues
20:28:27 <dipohl> especially the thoughts about care for security are important as I see it
20:29:03 <sumpfralle> yes, indeed
20:29:20 <sumpfralle> which specific paragraphs would you think, should be moved from the README to the guide?
20:29:46 <dipohl> I have not a concrete concept at the time..
20:29:58 <dipohl> let's talk again next week?
20:30:02 <sumpfralle> yes
20:30:09 <sumpfralle> #endmeeting