| 00:23.40 | pabelanger | russellb: Like a boss |
| 00:28.41 | russellb | goes on a static code analysis bug fixing spree |
| 01:11.13 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 01:15.39 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 01:43.51 | opticron | russellb is winning at commits |
| 02:27.08 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 04:33.53 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.156) |
| 04:49.21 | *** join/#asterisk-dev zh-tab (~zerohalo@74.61.196.236) |
| 07:19.27 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:19.29 | schmidts | good morning |
| 08:15.11 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:15.11 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:53.07 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 10:14.04 | *** join/#asterisk-dev Tim_Toady (~fuzzy@178.128.154.87.dsl.dyn.forthnet.gr) |
| 12:10.38 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:10.39 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:42.27 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ksnmlacaoakpidhn) |
| 12:42.40 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:49.34 | seanbright | russellb: good man |
| 12:52.07 | kpfleming | looks like someone has been addressing coverity scan results in asterisk |
| 12:52.21 | leifmadsen | freak out |
| 12:52.39 | leifmadsen | unfortunately no commits showed up in #asterisk-commits for me :( |
| 12:52.55 | seanbright | the bot is dead |
| 12:56.59 | leifmadsen | oh the humility! |
| 12:57.28 | jsmith | kpfleming: Wait... is this a dream? Can it be real? |
| 12:57.32 | jsmith | pinches himself |
| 12:58.05 | russellb | O.O |
| 12:58.47 | snuff-home | so we finally did get permission/pay for coverity scanning of * code base |
| 12:59.31 | kpfleming | redhat did it |
| 12:59.48 | kpfleming | and we've got it on our internal task list to address the results as part of asterisk 11 development, but russellb did some anyway |
| 12:59.58 | russellb | i got the itch |
| 13:00.05 | kpfleming | there's a cream for that |
| 13:00.10 | russellb | heh |
| 13:00.40 | russellb | there's plenty of fun left to be had i think |
| 13:00.58 | leifmadsen | THERE IS TO BE NO FUN |
| 13:00.59 | kpfleming | yep |
| 13:01.12 | kpfleming | replaces leifmadsen with sizeof(void) |
| 13:01.17 | russellb | ooh neat |
| 13:02.48 | jsmith | A couple of years ago, I ran Asterisk through the clang analyzer as well -- but nobody seemed interested in the results |
| 13:03.26 | leifmadsen | kpfleming: good thing I don't know what that means (or choose not to know what it means), so I'm still here! |
| 13:03.38 | seanbright | jsmith: did you say 'please?' |
| 13:03.43 | leifmadsen | s/choose not to/choose to not/ |
| 13:03.48 | leifmadsen | OR SOMETHING!@ |
| 13:03.51 | leifmadsen | FUN FOR ALL! |
| 13:03.59 | leifmadsen | blames the strong coffee.... |
| 13:04.19 | jsmith | seanbright: I did -- I even got a training client to run Asterisk through Coverity and submit the results (supposedly) |
| 13:04.46 | jsmith | seanbright: Although after that, I never heard another word |
| 13:07.07 | kpfleming | i've never seen coverity results until recently |
| 13:07.11 | russellb | same |
| 13:07.37 | kpfleming | and it's really not lack of interest... it's that processing these type of scan results is hard work, lots of false positives, and most of the problems reported don't actually affect anyone |
| 13:07.55 | leifmadsen | I Asterisk through some system that Russell had access to, which seemed to take about 4-5 days and was somewhat difficult to get setup right. I don't remember the name though. |
| 13:08.06 | kpfleming | some of them are serious, but of course they have to be found in the reports |
| 13:08.39 | russellb | leifmadsen: ah yes, that was something else ... huge PITA to use |
| 13:08.52 | russellb | leifmadsen: i think we were effectively beta testing it for them, heh |
| 13:09.03 | russellb | which would have been worth it if it didn't suck |
| 13:09.07 | kpfleming | clang's static analyzer is useful too |
| 13:09.20 | leifmadsen | russellb: agreed... I forget who it was... neat interface, but ya, huge PITA |
| 13:09.40 | leifmadsen | russellb: and I suspect (although not confirmed) part of the analysis was done manually... |
| 13:14.30 | kpfleming | the really useless reports we've received have been the supposed 'licensing problems' produced by the Black Duck scanner... wow, so useless |
| 13:18.00 | kpfleming | anyone feel like debugging the 'udp daemon of asterisk' this morning? |
| 13:18.53 | russellb | i'll only debug the ethernet over atm over voip daemon, kthx |
| 13:20.23 | kpfleming | on a totally related note, new South Park tonight |
| 13:23.46 | russellb | kpfleming: be sure to install your anti-virus HDMI cable before you watch it. http://i.imgur.com/VPcFx.jpg |
| 13:25.20 | kpfleming | lolz |
| 13:33.17 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:33.17 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 14:10.11 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:10.11 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:16.44 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:16.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:23.40 | sruffell | mjordan, putnopvut, and anyone else: What do you think about changing the commit message template to add in a general subsystem identifier as the beginning of the one line summary? Is there anyone else who would find this useful? |
| 14:24.42 | putnopvut | Can you give an example of what you mean? |
| 14:25.44 | sruffell | http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=shortlog <— You can see just from looking at the beginning of the summaries (for the most part) if the change touches a part of the code base that affects you. |
| 14:26.17 | sruffell | Asterisk is big enough that it could probably benefit from a convention like that as well. |
| 14:26.41 | mjordan | sruffell: I like the idea in theory, but I'm not sure how we'd handle check-ins that touch a large number of files |
| 14:27.08 | sruffell | If it's across subsystems…..then, yeah, drop it….but if it is, it's a big help. |
| 14:27.20 | sruffell | But if I'm the only one…..meh….just thought it could be helpful for others. |
| 14:27.40 | sruffell | I mean, but if it's not accross subsystems, but only affects certain parts, then yes. |
| 14:28.13 | mjordan | I wouldn't say that its only you. There's been other input from other sources that requested other tags as well (fixes that resolve crashes, for instance) |
| 14:29.35 | putnopvut | I'm kind of "meh" on the matter myself. |
| 14:32.08 | kpfleming | my personal opinion is that that information belongs in the issue tracker issue that the commit references |
| 14:32.25 | kpfleming | commit messages are not a database :-) |
| 14:33.57 | sruffell | heh. We'll have to disagree there. But ok…I'm not pushing for this, just though it might help. |
| 14:35.00 | kpfleming | given the already artificial length limitations imposed on the first line of the commit message by most Git deployments, i can't see how using up that space with tags could be beneficial |
| 14:38.30 | sruffell | I just find it very convenient while following projects that use git. Makes the summary more useful to me. I don't have to read as far into the email/commit message to see if it's something I care about. http://git.kernel.org/?p=git/git.git;a=shortlog and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=shortlog for example. |
| 14:38.35 | kpfleming | in the list you linked above, i also see tags of 'bugfix', 'dahdi' and others that don't seem to provide much value |
| 14:39.07 | sruffell | dahdi means it's a change in the core of dahdi, and not on ln one of the drivers…bugfix is not something that I personally put in, etc.. |
| 14:39.10 | kpfleming | i'm confused, you are talking about email commit messages, but posting links to git shortlogs |
| 14:39.25 | sruffell | I'm talking about the format of the oneline summary in the commit message template. |
| 14:39.29 | kpfleming | in the email commit messages, the list of files touched is very near the top of the email |
| 14:39.51 | kpfleming | so if you don't care about the files you see listed there, don't read the message |
| 14:40.25 | kpfleming | honestly, i'd be much more concerned about skipping over a commit message that i shouldn't have skipped over because the tags told me i didn't need to care when i really did |
| 14:41.49 | sruffell | ok..it was just an idea. |
| 14:42.06 | kpfleming | sure, and i appreciate that. i'm trying to understand how it would be helpful. |
| 14:42.37 | kpfleming | my concern is that the relevance of such tags is in the eye of the beholder, and so whether the tags in any particular message are helpful or not depends on the reader. each reader is different. |
| 14:43.29 | kpfleming | in the case of asterisk, i regularly skip reading commit emails when i can see that all the files touched are in chan_ooh323, for example |
| 14:43.53 | kpfleming | but sure, it requires me to do more than look at the first line of the message to do that. i don't find that objectionable. your mileage may vary. |
| 14:48.32 | sruffell | it probably is more a function of how much I use git. In many views on a repo, all I'm looking at initially is the one line summary, whether I'm using tig or using the "oneline" option to log to pack more information in a screen. |
| 14:49.05 | sruffell | so…I can see how it's just wasting space in an asterisk oneline summary. |
| 14:49.08 | kpfleming | right, that was my point earlier. this is a very different discussion from the actual emailed commit messages themselves. |
| 14:50.12 | kpfleming | i've never used the tool itself to look through the repository for commits i might need to read... that's what the commit mailing list is for. the repository is an archive for later use, if necessary :-) |
| 14:50.23 | sruffell | yeah…I look at the emails for the other projects…but I do use git to follow asterisk so for me personally, those commit summaries still are significant. But admittedly only for me most likely. |
| 14:51.05 | kpfleming | yeah, so that's the big difference. none of use git/svn itself to follow the work. we use the mailing list. |
| 14:51.58 | russellb | i use git to follow asterisk fwiw, heh |
| 14:52.13 | kpfleming | as your local repo, or to see what activity has taken place? |
| 14:52.25 | russellb | both |
| 14:53.11 | kpfleming | interesting. if i did that, i'd have to use some sort of viewer that showed the entire commit message in a pane of the window... i'd never find the one line summaries useful enough on their own. |
| 14:53.18 | sruffell | tig does that |
| 14:53.28 | kpfleming | actually, the commit message and the list of files touched |
| 14:53.32 | russellb | or gitk, gitg, qgit, etc |
| 14:53.38 | sruffell | nods |
| 14:53.41 | sruffell | <3 ti |
| 14:53.42 | sruffell | g |
| 14:53.49 | sruffell | haven't used those other ones though... |
| 14:53.54 | sruffell | well..and gitweb |
| 14:54.08 | kpfleming | not quite the same thing |
| 14:54.18 | russellb | those other 3 seem just about the same to me, just pick your UI toolkit, heh |
| 14:54.20 | sruffell | heh..true |
| 14:54.23 | kpfleming | gitweb doesn't allow you to scroll down commit by commit and see the commit message appear next to it |
| 14:54.41 | tzanger | jeez I step away for a minute and the channel's full of meaty tech talk |
| 14:54.57 | kpfleming | so how do you keep track of what you have reviewed and what you haven't, if you are just browsing the repo itself? |
| 14:55.27 | russellb | i'm not trying to keep track, so that helps, :-p |
| 14:55.36 | russellb | so i know i miss stuff |
| 14:55.56 | russellb | but i guess you could do something like, review the changes between upstream and your local branch, then rebase |
| 14:57.23 | kpfleming | so that goes back to the point i attempted to make earlier... the processes we are talking about here are highly subjective, and really have a great deal to do with the context of the review/activity tracking itself. |
| 14:57.33 | kpfleming | if the goal is to review all activity, the mailing list is ideal. |
| 14:57.45 | kpfleming | if the goal is to see "has anything broken my branch" then that's very different. |
| 14:58.02 | sruffell | Yes…I agree with that…..email is ideal when following everything. |
| 14:59.25 | kpfleming | so if you have specific areas of interest/disinterest, my thoughts are that it would be much better to improve your reviewing/tracking tool to have filters to allow you to include/exclude stuff you don't care about, rather than putting the burden of that on the committer (and having it be subject to being wrong or incomplete) |
| 15:00.04 | kpfleming | for example, if you don't care about stuff under xpp/, then tell tig/gitk/etc. to just not show you any commits that consist entirely of changes under xpp/ |
| 15:00.40 | sruffell | I like putting all the burden on the committer. :) Assuming that there are multitudes of reviewers / followers for each committer. Saves more time overall. |
| 15:01.02 | sruffell | but I see your point. |
| 15:01.44 | kpfleming | does it? what if one reviewer doesn't care about xpp/, but another reviewer only wants to see header file (API) changes. how can the committer tag things to satisfy those desires? |
| 15:02.44 | sruffell | if it's dahdi wide…just don't tag it since it can't be limited. |
| 15:02.59 | kpfleming | you missed my point completely. |
| 15:03.07 | kpfleming | a commit changes xpp/foo/bar.h. |
| 15:03.19 | kpfleming | reviewer 1 doesn't want to see it because they don't care about xpp/ |
| 15:03.30 | kpfleming | reviewer 2 wants to see it because it touches a header file. |
| 15:03.43 | sruffell | but that header file is xpp specific…I would just tag it xpp personally. |
| 15:03.47 | kpfleming | the 'xpp' tag on the commit helps reviewer 1, but not reviewer 2, for them it's just misleading. |
| 15:03.55 | kpfleming | are you reviewer 2? |
| 15:04.16 | sruffell | I'm the committer..I'm making a change that only affects users of xpp. |
| 15:04.25 | sruffell | even if it's just an xpp header. |
| 15:04.34 | kpfleming | then that's a totally different meaning for the tags. |
| 15:05.12 | kpfleming | what if reviewer 2's goal in reviewing code is to ensure that all headers that expose APIs conform to guidelines, but they don't review the actual code? |
| 15:05.32 | kpfleming | that seems reasonable, but no tag i can think of is useful. |
| 15:05.40 | kpfleming | a filter in the viewing tool would take care of it, though. |
| 15:06.29 | sruffell | yes…I think so. |
| 15:06.37 | kpfleming | i guess i'm just very stuck in the mindset of not repeating data that exists elsewhere (from my database days). the information you need to select what to review already exists. |
| 15:06.52 | kpfleming | it's just not in a form you can use, because the tools don't let you use it that way, although they could. |
| 15:08.36 | kpfleming | could not remember the freaking word... normalization (from database land). don't store data that can be trivially calculated from data already stored, especially if that could allow it to become stale or inaccurate. |
| 15:09.12 | kpfleming | if the 'calculation' involves subjectivity, then it's even riskier. |
| 15:10.22 | sruffell | nods |
| 15:11.21 | sruffell | often times though it can be a simple reording of words already in the summary. I.e. "Fix memory leak" <— bad "Fix memory leak in chan_dahdi" <—still bad "Fix memory leak in chan_dahdi when bridging calls" <— ok. "chan_dahdi: Fix memory leak when bridging calls" <— I like. |
| 15:11.29 | kpfleming | and now i must prepare for going to the office, because i've worked too many hours at home this morning :0 |
| 15:12.18 | kpfleming | oh, i'm not suggesting that putting the information in that way is not beneficial... it certainly can be. my concern would be coming up with any sort of policy that attempted to codify a process for tagging. |
| 15:14.20 | kpfleming | but if you had a filter that showed you all commits that touched chan_dahdi.c, it wouldn't matter |
| 15:18.08 | russellb | sruffell: i like that convention myself ... |
| 15:18.14 | russellb | i should try to use it, heh |
| 16:32.28 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:32.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:38.33 | kpfleming | we have a number of people in this chat that are users/masters of puppet, no? |
| 16:39.17 | russellb | points at pabelanger |
| 16:39.46 | Qwell | the master of puppet is calling his name |
| 17:04.46 | *** join/#asterisk-dev alexoc (~alexoc@187.106.48.119) |
| 17:12.07 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 18:41.54 | leifmadsen | has used puppet, but is now using chef more than puppet |
| 18:42.40 | russellb | i have "used" it, but don't claim that i remember much |
| 18:54.37 | pabelanger | o/ |
| 18:55.38 | kpfleming | well, i learned what i needed to from the google |
| 18:56.10 | kpfleming | my question was going to be something like "can we securely connect puppet clients that are located on the wild internet to a puppet master located in our corporate network?" |
| 18:56.37 | kpfleming | and the answer appears to be yes, we can open a firewall port to allow connections to the puppetmaster, and then the existing puppet TLS+cert authentication stuff would keep it secure |
| 18:58.08 | kpfleming | plus we can restrict the source IPs to our blocks of assigned addresses, so i'm comfortable |
| 18:58.11 | kpfleming | and now back to asterisk... |
| 18:58.22 | file | Asterisk? what's that? |
| 18:59.11 | pabelanger | yup, puppet clients need to have their keys signed to access the puppet master, unless you have autosigned enabled |
| 18:59.28 | kpfleming | which we would not |
| 18:59.47 | kpfleming | if we failed to block IPs, anyone could connect a puppet client and send their cert to the master, but we'd never sign them |
| 19:00.01 | kpfleming | so while that's not ideal, it's not a huge problem |
| 19:35.01 | elguero | exit |
| 19:35.19 | elguero | doh... ignore me |
| 19:35.37 | seanbright | so... with lumenvox's per port licensing |
| 19:35.58 | seanbright | does that only count the time between SpeechCreate and SpeechDestroy? or is it for the life of the asterisk channel? |
| 19:36.08 | seanbright | (and yes, i know this isn't a lumenvox support channel) |
| 19:36.21 | file | between SpeechCreate and SpeechDestroy |
| 19:37.55 | seanbright | thank you, sir. |
| 20:10.58 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 20:10.58 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Tier 4 support is in #2,000 |
| 20:13.00 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 20:13.00 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Tier 4 support is in #2,000 |
| 20:14.31 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 20:14.31 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Tier 4 support is in #2,000 |
| 20:20.42 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-likddhrgqvdosfls) |
| 20:20.42 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:21.46 | *** join/#asterisk-dev alecdavis (~alec@210.48.127.227) |
| 20:21.51 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 20:21.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:22.55 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 20:22.56 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:22.56 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-xrafeuuraoyabkou) |
| 20:58.46 | alecdavis | @sruffell: i think dahdhiblacklist.sample should also have the know incompatible drivers. ie. hfcmulti vs wcb4xxp |
| 20:59.29 | sruffell | alecdavis: I hfcmulti was in that list that I sent, wasn't it? |
| 21:02.28 | alecdavis | yes, hfcmulti was in the list, but it doesn't say that it's incompatible with wcb4xxp. |
| 21:02.45 | alecdavis | re netjet, what's it incomptabile with. |
| 21:02.56 | alecdavis | and hfcpci? |
| 21:04.18 | alecdavis | spelling not good today. arm in a cast :( |
| 21:12.29 | sruffell | ahh…I got it…that's a good point. |
| 21:12.37 | sruffell | why is your arm in a cast? |
| 21:22.03 | alecdavis | roller skating with my 9 year old son, at rink, 3 saturdays ago. |
| 21:23.07 | alecdavis | I need to stop think im indestructable. Seem to be getting fragile :) |
| 21:53.48 | tzafrir_laptop | hfcpci is for zaphfc |
| 21:55.02 | tzafrir_laptop | In the other news, gmime 2.4 is now obsoleted in Debian Testing for gmime 2.6 |
| 21:56.16 | tzafrir_laptop | sruffell, patch looks OK to me. |
| 21:57.43 | tzafrir_laptop | Though the netjet driver shouldn't really be handling those dahdi cards |
| 22:19.38 | sruffell | It shouldn't…but there is only one subvendor, subdevice that is excluded... |
| 22:20.02 | sruffell | I just sent http://article.gmane.org/gmane.linux.network/223913 to netdev today for a problem. |
| 22:27.06 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 22:27.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 22:39.06 | russellb | is something eating origsvn? it's taking forever to complete actions |
| 22:47.27 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 23:21.14 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-xvmlwobneevwmodq) |
| 23:50.12 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
