18:00:50 #startmeeting 18:00:50 Meeting started Tue Oct 29 18:00:50 2013 UTC. The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:07 woo. on time today! 18:01:14 hi everyone! 18:02:08 so, agenda for today is quite common : 2.2, munin-c, q&a. 18:02:37 feel free to talk when you want. (as usual) 18:02:46 #topic 2.2 18:03:37 sql branch is progressing again. the overview and service page are done. 18:03:52 current work is on the node page. 18:05:04 sql is very easy tp work with. 18:05:45 it even makes up for very readable code. 18:06:54 imho, and compared to old. 18:08:09 the html datastruct is not. reverse eng it is easy, but very time consuming. 18:09:40 nice part is I think i'll might rewrite the graph CGI and limits also, to make use of the SQL backend. 18:10:08 dunno if it'll be ready for 2.2 18:13:55 re 18:14:09 sorry, the road were terrible 18:14:39 will add my agenda points when appropriate 18:15:39 speed of cgi+sql is quite decent. currenlty 100ms for 200+ nodes in plain CGI mode (no FCGI yet) 18:16:04 so, that's it for 2.2 18:26:50 question ? 18:29:23 Hm? 18:30:33 do you have an idea of the "initialization overhead" 18:30:46 (i.e. what proportion of those 100ms will be gained through fcgi) 18:33:54 olasd: no idea. 18:34:07 right :0 18:34:10 :)* 18:36:00 but i'm afraid that init time is fairly minimal, since the cgi is now only 1 file. 18:36:49 which is about 6KiB long. 18:40:28 ... and about 200 LoC. 18:40:48 SQL is *very* expressive. 18:41:28 #topic munin-c 18:41:38 so, moving to munin-c 18:42:12 in order to focus on sql, i asked helmut to take the interim on m-c. 18:43:07 i made several pull req on various feats. 18:43:34 the biggest one being config parsing, that should be the same as mainline munin-node. 18:43:43 (hint, it isnt yet) 18:44:32 i'm also busy deploying it to many win32 nodes. currently via cygwin. 18:47:09 the win32 port does benefit from a new, external_ plugin, that completely delegates the actual data gathering to an external process. 18:47:31 like the procmon or some powershell tools 18:48:37 ... as the current m-c policy is not to have "more" feats than mainline, i'll write an shell based external_ official plugin also. 18:50:45 end. questions ? 18:51:51 #info in order to focus on sql, i asked helmut to take the interim on m-c. 18:52:22 #topic misc 18:52:34 now, free-for-all ! :) 18:52:49 I'd like to discuss up to four things 18:53:00 first, bugs and handling of them 18:53:39 I checked a lot of recent bug reports, quite a lot of them just should be applied 18:53:45 #topic misc/bugs 18:54:24 you mean they contain patch ? 18:54:35 often they do 18:55:04 Aside, I was thinking about a bot that gates new tickets and comments on tickets into this channel 18:56:29 So, honestly, my impression is the bug tracker doesn't get that much attention 18:57:28 it doesnt. that is a fact. 18:57:43 a sad one, but nonetheless a true one. 18:58:05 #action add an irc trigger on trac actions. 18:59:03 So, should I create a git branch somewhere with the patches I consider sound? Would that help? 18:59:31 However, patches that _I_ created should be reviewed by somebody else 19:00:09 i'll review any patch :) 19:00:31 so, putting them in branch would be awesome 19:00:54 OK 19:01:47 I'd like to ask for your special attention for #1394. If accepted, this should even go into a Debian point release 19:01:53 * TheSnide tends to abuse github's pullreq feature as a todo. 19:02:56 More about bugs? 19:03:25 sur 19:03:26 e 19:03:35 then discuss 19:04:03 i'll take a look at that one, 19:07:38 (/me is at a terribly noisy place, so I'd like to push a bit) 19:10:46 So, I'd mention three projects I have in mind. Two of them I'd just start, these are: 19:11:10 btw, /me is using helmut's way for bugfixes. 19:11:35 - rewrite all plugins to use the "dirtyconfig" feature whenever possible. This should speed up data acquisition over slow links 19:12:18 start a branch for each fix the earliest possible, then merge them on a common bugfix branch. that way each commit can still be merged individually where needed. 19:13:09 for dirtyconfig, Flameeye1 also started fusing some plugins together via multigraph 19:13:39 so, both optimizations could be done quite easily where applicable. 19:13:48 Don't get the full idea behind that branching but this might be due to local circumstances. We'll discuss that another time 19:13:57 - Second project, do a major rework on the handling of multigraph. There are issues that really make me frown, but changes might break some plugins 19:13:58 so, +1 (in case it wasnt obvious) 19:14:44 i think the most valid issue is the leading _. 19:15:18 that all pure numeric field gets squashed away to "_" is quite annoying. 19:15:33 There's a ticket about that :-> 19:15:40 i know. 19:15:54 might even be yours... 19:16:01 It is 19:16:06 :D 19:16:37 but changing any protocol, even slighly, is 3.0 material to me. 19:17:00 The last thing might require more discussion. So, just the idea: Have munin-graph and munin-cgi-graph running under the same user-id (that would probably be www-data). Same for html 19:17:03 _adding_ isnt, _changing_ is. 19:17:33 for uid, there's a lot more to say. 19:20:08 as, i'd like a separate uid of m-node, m-a and munin master 19:20:25 OK, part of a bigger architectural change 19:20:31 yep. 19:20:50 not earlier than 3.0 anwyay. 19:21:06 Point, I'm interested in that one since it would ease hybrid mode (#1393) 19:22:13 GrumpyFux: could you craft a wiki/branch/whatever thing that brings some particular bugs on my radar ? 19:22:48 * TheSnide is currenlty rushing to finish sql before end of year :) 19:22:53 * GrumpyFux takes a mental note 19:23:22 thx 19:24:01 anything else ? 19:24:22 (anyone) 19:25:18 end meeting in 5 min timeout otherwise 19:25:33 nothing here 19:27:24 thx all. 19:27:27 #endmeeting