19:39:28 <TheSnide> #startmeeting
19:39:28 <MeetBot> Meeting started Tue Aug 26 19:39:28 2014 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:39:28 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:40:13 <TheSnide> hi all, short meeting again today. nothing really new.
19:40:33 <TheSnide> dipohl did manage to setup a nice plugin gallery
19:41:00 <TheSnide> it looks promising...
19:41:56 <TheSnide> i'd like to have oauth identification, so we delegate the spammy user fighting to github
19:42:48 <TheSnide> having a regular user login would be nice for us, if oauth gw does not work.
19:43:16 <TheSnide> .. but regular login would be the exception, not the norm.
19:43:34 <TheSnide> well, that sums it up
19:43:40 <TheSnide> anything else ?
19:50:43 <dipohl> concerning the plugin gallery I have some plugins I want to put into another category
19:52:52 <dipohl> I put the yum plugin to category "updates" and would like to add there also "apt" (now in "other") and "apt_all" (now in "system")
19:53:31 <dipohl> TheSnide: Accepted?
19:55:55 <TheSnide> hmm.
19:56:38 <TheSnide> Packaging or distrib would be better
19:58:21 <dipohl> They all monitor how many "updates" are pending
19:59:40 <dipohl> So "updates" is addressing the issue very clear
20:02:26 <TheSnide> but updates of what ??
20:03:21 <TheSnide> (sorry for the double ?)
20:07:21 <dipohl> I would expect most peoples association will go in the right direction
20:08:03 <dipohl> But I will think further
20:08:55 <dipohl> Here another candidate in question: The multigraph plugin meminfo refers to the following categories
20:08:55 <dipohl> 'memory', 'cache', 'active_inactive', 'direct_map', 'kernel', 'low_and_high', 'hugepages', 'total', 'allocates', 'objects','groups_size', 'writeback', 'candidates', 'processes'
20:09:46 <dipohl> I don't like this inflation of new categories with only one plugin refering to them
20:13:51 <TheSnide> bushmills started a cat::sub scheme
20:14:50 <m-r-b> <Bushmills@freenode> just single colon, actually
20:16:03 <m-r-b> <Bushmills@freenode> hints of it visible on http://demo.munin-monitoring.org, with the network:... categories
20:17:24 <m-r-b> <Bushmills@freenode> but TheSnide picked it up, with the 1sec::... category
20:18:46 <dipohl> Bushmills: TheSnide and me talked about /tagging/ categories
20:19:12 <dipohl> I tend to think, that this is the better solution
20:19:31 <dipohl> as you will get more flexibility
20:20:11 <dipohl> e.g. in the category "memory" the proc plugin about process memory can also show up
20:20:24 <dipohl> but also in "processes"
20:20:33 <m-r-b> <Bushmills@freenode> seems it's merely a matter of convention, not of code change
20:22:08 <m-r-b> * Bushmills@freenode knows who is especially happy about this
20:22:40 <dipohl> We need to announce conventions to care for good conditions to auto-generate the plugin gallery
20:23:01 <TheSnide> each plugin shall have a category and then a set of tags
20:23:23 <TheSnide> like gid in unix
20:23:35 <dipohl> we could use the magic markers
20:23:44 <dipohl> for category tags
20:23:57 <TheSnide> for tagging ? yep, would be good idea
20:24:26 <TheSnide> tag:whatever
20:24:40 <dipohl> the magic marker "capabilities" is also 1:N, so it should work
20:24:42 <TheSnide> tag:what::ever
20:24:54 <TheSnide> tag is what::ever
20:25:15 <m-r-b> <Bushmills@freenode> If I were to redo it, i'd possible put plugins or their links into subdirectories, and use their names as categories
20:25:56 <TheSnide> btw, i need to go, so i'll just leave the meeting. be back at 2300 cet
20:25:58 <m-r-b> <Bushmills@freenode> user preferences differ, but sources want to be kept identical
20:27:07 <dipohl> TheSnide: ok
20:28:08 <dipohl> Bushmills: service links in subdirectories imply a 1:1 relation, right?
20:28:38 <dipohl> as you don't want double service links (which would trigger double run of the plugin..)
20:28:39 <m-r-b> <Bushmills@freenode> that would be the idea, yes
20:29:35 <dipohl> I think the big advantage of tagging is, that you can build multiple relations
20:30:14 <dipohl> the graph could show up in different contexts
20:30:30 <m-r-b> <Bushmills@freenode> i suppose of you really have to, you could still express those in plugin conf or plugin source
20:31:20 <m-r-b> <Bushmills@freenode> for most plugins, a single category should be fine - and one could change that without modifying either plugin source nor conf
20:31:53 <dipohl> I come to it because of the multigraph plugins
20:32:21 <dipohl> At least there we need a 1:N relation
20:32:53 <dipohl> One plugin _file_ but many plugins
20:34:44 <dipohl> Parsing the plugins file would be easy, if the categories are declared in a strict manner
20:38:54 <kenyon> they are declared in a strict manner
20:39:22 <kenyon> execute the plugin and parse the categories just like munin does
20:40:19 <dipohl> kenyon: that is not possible for many plugins
20:40:28 <dipohl> which needs manual configuration
21:02:52 <TheSnide> ok, ending the meeting.
21:03:00 <TheSnide> #endmeeting