| 00:10.36 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 00:28.53 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 00:53.34 | *** join/#asterisk-dev russellb (~russellb@asterisk/contributor-and-cool-guy/russellb) |
| 00:53.34 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:53.35 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 00:53.35 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 01:41.20 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:41.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:42.10 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 05:08.06 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 05:08.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:14.52 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 05:14.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:30.40 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:30.42 | schmidts | good morning |
| 06:54.52 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:06.18 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:06.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:19.14 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 07:19.14 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 07:24.18 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:32.43 | *** join/#asterisk-dev oej (~olle@office.ipvision.dk) |
| 07:32.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:32.52 | oej | Good morning folks |
| 07:33.32 | mvanbaak | good mornin |
| 07:38.22 | schmidts | morning oej |
| 07:39.29 | oej | The european crowd is on line :-) |
| 07:39.48 | oej | I would like to organize a 1.8 bash camp somewhere in Europe. |
| 07:40.09 | oej | 10-20 geeks, a set of servers and 1.8 testing/hacking/fixing |
| 07:40.22 | oej | I need to get up on 1.8, but I need a 1.8 that works first. |
| 07:43.35 | mvanbaak | good idea ! |
| 07:44.14 | wdoekes2 | ( someone with commit powers: a one line s/4599/4999/ fix in v10 before it gets out of beta: https://issues.asterisk.org/jira/browse/ASTERISK-16250 ) |
| 07:46.24 | oej | Arrggghh. Still doesn't work with Safari. |
| 07:48.36 | mvanbaak | uhhuh, annoying isn't it? |
| 07:53.27 | jmls | oej: you need to move to a better O/S, like windows .... :-D |
| 07:54.13 | oej | ha ha . . . Good joke - not. |
| 07:56.27 | schmidts | :D |
| 07:56.54 | schmidts | oej why not in austria ;) if it would be here you can count me in |
| 07:57.17 | oej | Well, if you can get a room for a few days and the servers, I am fine with Austria. |
| 07:58.01 | schmidts | hmmm not impossible ;) which date do you want to do this? |
| 07:58.08 | oej | Argh. Simplejson doesn't exist |
| 07:58.26 | oej | I am juggling a lot of things around, but would expect october timeframe |
| 07:59.24 | mvanbaak | I can donate two IBM X345 servers |
| 07:59.53 | schmidts | we have enough DL360 or DL380 as Spare so this wouldnt be a problem ;) |
| 08:00.33 | mvanbaak | oh, and I can probably fix a dozen of VPS-es |
| 08:20.50 | oej | Sounds like a cool thing to do. Looking at the calendar, october is filled. |
| 08:21.08 | oej | November 7-9 ? |
| 08:21.18 | oej | Or if we can start over the weekend. |
| 08:24.59 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:25.00 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 08:38.05 | oej | I have a cool SIP channel branch - the pine-brutal-sip-experiments |
| 08:38.17 | oej | In there, I can load two sip channels in one Asterisk |
| 08:41.39 | schmidts | oej oh cool, i have take a look at the code when you started with this ;) |
| 08:45.33 | oej | I think it's cool, since you can separate interfaces or IPs correctly now. |
| 08:46.07 | oej | I just wonder if I need to change the SIP_PEER dialplan functions and CLI functions to show all objects, regardless of channel... |
| 08:48.23 | oej | Cleaning day :-) |
| 08:56.23 | schmidts | oej ;) i am still thinking about a way to split up the incoming procedding of sip messages and the scheduled messages, cause with this asterisk should be able to handle much more load than now |
| 08:57.32 | oej | Yes. |
| 08:57.53 | oej | The SIP channel is so messed up so it may be easier to restart |
| 08:58.12 | oej | But just for fun, how would we split up the monitor thread? |
| 08:58.44 | oej | In pinana, I'm trying to have a separate thread for the PUBLISH/SUBSCRIBE/NOTIFY messages. I don't remember if I got it working. Will restart that project soon. |
| 09:00.30 | oej | If we take the SIP model, we could create a transaction layer per socket or transport with different threads. |
| 09:00.46 | oej | Then worker threads that takes the message and process it above that layer. |
| 09:01.05 | oej | We need an outbound queue dispatcher that puts message on the queue for the transaction layer to handle. |
| 09:05.10 | schmidts | oej it depends on which version you are looking for? in 1.10 you have 4 functions. 1 to clean up all rtp timeout stuff, 1 to delete old dialogs, 1 to wait and read the buffer until the next scheduled message should be send and 1 to do the scheduler, imho you could move the scheduler to an own thread so the only thing you have to do is to wait for incoming messages for 1 ms, check old dialogs and then wait again |
| 09:06.09 | oej | Well, that will still cause congestion in that thread. |
| 09:07.06 | oej | All the incoming message processing runs in that thread. The question here is what it is that consumes time? Message parsing and matching with dialogs? Processing? |
| 09:11.26 | oej | I don't like hunks that FAIL. |
| 09:12.53 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 09:14.22 | *** join/#asterisk-dev asterisk-Tester (~RAMYT@210.5.215.40) |
| 09:18.47 | schmidts | oej i have allready tried to split receiving and processing into two thread, but also russell and kevin meant it would be better to move the scheduler to a own thread, cause you dont have to copy the whole sip pvt when its received |
| 09:19.39 | schmidts | btw this only depends on UDP for TCP there is a own thread for each connection |
| 09:20.11 | schmidts | oej https://reviewboard.asterisk.org/r/970/ this was the idea i had |
| 09:22.16 | oej | Please enlighten me - why would you have to COPY the pvt? |
| 09:22.57 | schmidts | oej you have to copy the message from the buffer into the pvt |
| 09:23.11 | schmidts | and i think i have just copied the buffer before give it to the other thread |
| 09:24.58 | *** join/#asterisk-dev felipe_ (~felipe@unaffiliated/felipe) |
| 09:28.26 | oej | Yes, we need an improved message structure, but we don't need to copy the actual pvt. Now I get it. |
| 09:28.55 | oej | Having a proper message buffer would help retransmits, which we don't do properly today. |
| 09:30.18 | schmidts | yes thats true |
| 09:50.26 | oej | More hunks that fail. Damn you hunks. |
| 09:58.06 | oej | So we need an ast_obj that is the message (request or response) that we send around. |
| 09:58.31 | oej | Right now we copy stuff a couple of times. I had a branch around that optimized that a while ago. |
| 11:23.26 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 11:23.55 | leifmadsen | oej: that branch you're working on, you might want to look at the /b modifier to make sure that code shouldn't be going there (or that it doesn't do what you want) |
| 11:24.24 | leifmadsen | I would expect /b should do what you're coding up (if it doesn't do it now, it probably should) |
| 11:27.35 | oej | The local bridgeflags stuff? |
| 11:27.37 | oej | I'll check |
| 11:28.08 | oej | I have had this branch open for such a long time, it did not exist when I started :-) |
| 11:29.06 | oej | Where's documentation on that option? |
| 11:35.48 | oej | https://wiki.asterisk.org/wiki/display/AST/Local+Channel+Modifiers |
| 11:36.14 | oej | I don't think it's the same. |
| 11:36.33 | oej | With /b we "hide" the local channel. We still loose the options. |
| 11:36.35 | oej | Consider this |
| 11:37.05 | oej | You dial from SIP/x to Local/1000, which runs dial(sip/y,,T) |
| 11:37.20 | oej | When local disappears, the "T" option disappears to |
| 11:37.33 | oej | The only current option is to run /n, which means we have a lot of extra channels we don't need. |
| 11:38.19 | oej | Or do I misunderstand, LeifMadsen? |
| 11:41.17 | leifmadsen | oej: right, and I'm thinking when you use /b it should also do the same thing |
| 11:41.25 | leifmadsen | so you should actually "activate" that with /b |
| 11:42.11 | leifmadsen | so you use /b modifier to make it work like you expect -- I suspect you're right that it doesn't do that now, but that is where I think you should add the code (or at least trigger the code) |
| 11:45.44 | oej | I don't see a problem with doing this by default. Why should we let the dial options disappear? |
| 11:46.02 | oej | Does anyone want that to happen at any time? |
| 11:47.31 | oej | consider it a bug, really |
| 11:48.19 | oej | I guess /b is more about dialplan functions on the channel, that they apply to the channel behind. Which is something else. The documentation is kind of sparse. |
| 11:48.27 | oej | It could be a new option though. |
| 11:48.54 | oej | Or? |
| 11:50.29 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:50.30 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:55.23 | kaii | +1 for doing this by default. if my opinion counts. why would anyone actually want the T options (like the mentioned T) disappear at all. possibly there should be an option to make them disappear. but ignoring these by default seems wrong. |
| 11:55.54 | kaii | s/the T options/the dial options/ |
| 11:56.03 | oej | Well, if you add them to dial, you want them to apply to the call. If you don't want them (a.k.a. Disappear) then you don't add them to dial() |
| 11:56.31 | oej | there's no point in adding them to dial() if you want them to disappear as soon as the call is bridged. . . |
| 11:57.34 | kaii | youre right. this is unexpected behaviour that would be hard to debug for asterisk users |
| 11:57.35 | oej | Hmm. Seems like menuselect configure doesn't discover the proper path for libintl, which is part of gettext |
| 11:58.44 | *** part/#asterisk-dev asterisk-Tester (~RAMYT@210.5.215.40) |
| 12:05.10 | oej | So Leifmadsen, any further thoughts or reflections on bridge flags? |
| 12:05.40 | leifmadsen | I have nothing further at this time :) |
| 12:05.59 | oej | Do you agree with implementing this as the default behaviour? |
| 12:07.38 | oej | I guess you have more important things to bother with before disappearing into marriage ;-) |
| 12:08.40 | oej | Anyway, thanks for your ideas and feedback, Leif. |
| 12:12.34 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 12:16.47 | leifmadsen | oej: I can't think of any good reason why it shouldn't be implemented by default I guess |
| 12:16.59 | oej | Ok, so we agree then. Thanks :-) |
| 12:25.23 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 12:25.35 | oej | How do I get permission to change the wiki? I can't create pages |
| 12:26.07 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 12:26.45 | russellb | one of the admins will have to add you to the right group |
| 12:26.52 | kpfleming | oej: you should already have permissions... i'll check |
| 12:27.55 | kpfleming | huh... you were in fact *not* in the proper group. you are now, it will probably take about ten minutes for the wiki to notice the change. |
| 12:28.07 | oej | Ok, thanks. |
| 12:41.11 | kpfleming | oej: looks like it is working now |
| 12:41.57 | oej | Yes. |
| 12:41.59 | oej | THanks again |
| 13:02.12 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-nhjpkmmlnpxkktwj) |
| 13:02.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:06.28 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:51.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:51.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:15.14 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:15.14 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:22.27 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 14:23.33 | oej | mnicholson: WHy commit without a peer review? |
| 14:23.45 | oej | Anyway you should have DEFAULT_STORE_SIP_CAUSE in that commit |
| 14:34.21 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:34.21 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:36.01 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 14:38.49 | oej | DTMF is strange. |
| 14:44.38 | leifmadsen | +1 |
| 14:48.52 | pabelanger | mnicholson: re: 'storesipcause', if we believe this is a performance improvement for asterisk 1.8, I think we should set the value to 'no' in our sample configuration files. Overriding the default setting for new installation. IMO, must people do not read CHANGES and UPGRADE.txt files |
| 14:49.17 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:49.17 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:50.35 | oej | And set the code flag to TRUE in 10 and trunk... |
| 14:50.40 | kpfleming | we have a number of cases in the past where we've setup the sample config files to disable/enable something where the default is otherwise... and then in a later release we change the default |
| 14:51.02 | kpfleming | leifmadsen: pabelanger: mnicholson: ^^^ |
| 14:51.25 | kpfleming | so i think it would be fine to do that for asterisk 10 and trunk |
| 14:51.46 | kpfleming | and really, with as much performance degradation as you are referring to here, i'd consider changing it in 1.8 as well, with suitable notice to users |
| 14:51.47 | oej | I just noted that in event.h Russell writes that "since this is not in release code yet". I think it was release a long time ago. |
| 14:52.03 | kpfleming | oej: blame Air France/KLM |
| 14:52.46 | leifmadsen | kpfleming: ya, I think it should really be commented out, but to also match what the code shows ideally (as documentation to show what the defaults are) |
| 14:52.48 | oej | Absolutely. No doubt about it. |
| 14:53.03 | leifmadsen | reads "No doubt about it" with a Canadian accent |
| 14:53.14 | oej | +1 |
| 14:53.17 | kpfleming | well, we have plenty of cases where the sample config does not show what the default is |
| 14:53.23 | pabelanger | kpfleming: yes, that is my thinking too. If we are addressing a performance issue with Asterisk, disabling it in 1.8 gets my vote too. Even though we are mid release |
| 14:53.23 | kpfleming | so.. we're inconsistent tehre |
| 14:53.38 | oej | Yes. That's a tradition. |
| 14:53.52 | leifmadsen | kpfleming: that doesn't mean we shouldn't try :) |
| 14:54.07 | *** part/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:54.44 | leifmadsen | I'm not really sure what we should be doing, but having a policy of how to document the configuration option going forward would be useful I think |
| 14:55.02 | kpfleming | yes, it would be. but that's really a different discussion (also valid, though). |
| 14:55.22 | pabelanger | leifmadsen: +10000 |
| 14:55.41 | leifmadsen | we could even add it to the coding guidelines :)_ |
| 14:56.07 | pabelanger | leifmadsen: https://wiki.asterisk.org/wiki/display/~pabelanger/Configuration+file+spec |
| 14:56.10 | pabelanger | started that a while ago |
| 14:56.16 | leifmadsen | nice will check |
| 14:56.34 | pabelanger | and https://wiki.asterisk.org/wiki/display/~pabelanger/sample+config |
| 14:56.44 | kpfleming | really, you are talking about making the 'sample configs' actually be sample configs, and not documentation, and having separate documentation that covers each option, with its possible settings and default |
| 14:56.55 | pabelanger | indeed |
| 14:56.59 | kpfleming | the sample config files have really never been comprehensive |
| 14:57.09 | pabelanger | make sohopbx-samples |
| 14:57.25 | kpfleming | make toast-with-jam-yummy |
| 14:57.33 | leifmadsen | I've started on a set of sample configs that would actually be useful in the wild -- the rest of the stuff should just be moved to a wiki page and documented there |
| 14:57.41 | leifmadsen | or some other location that can be generated |
| 14:57.58 | leifmadsen | there probably shouldn't be a "make samples" using the files we're using now |
| 14:58.52 | kpfleming | make samples-you-really-dont-want-to-use |
| 14:59.05 | oej | ?don't move to wiki, don't move to wiki... |
| 14:59.22 | oej | We do need stuff in the source. The reference. |
| 14:59.41 | oej | But I agree, the "sample configs" are bad as they are today and we need a new concept, separate reference from samples |
| 15:00.28 | leifmadsen | http://svn.asterisk.org/svn/asterisk/team/lmadsen/sample_config_refactor/ |
| 15:01.21 | oej | We might want to put reference in the code, like we do with manager. |
| 15:01.51 | oej | I had that code once, with the config options in an array with a "description" field and one "type" |
| 15:02.02 | oej | Wonder where it was. Either astum or pineapple. |
| 15:02.08 | oej | Old stuff. |
| 15:02.48 | leifmadsen | I'd suggest better named branches :) |
| 15:03.08 | pabelanger | I've often though about using the same concept for inline xmldoc but for configuration files. |
| 15:03.24 | leifmadsen | maybe our configuration files should just be in xml? |
| 15:03.27 | leifmadsen | ducks and covers |
| 15:03.50 | mjordan | why would you want to use a configuration format that can be validated? |
| 15:03.57 | pabelanger | descriptions and default values would be nice, from a documentation POV |
| 15:04.16 | pabelanger | mjordan: parsers, wikibot |
| 15:04.42 | mjordan | rhetorical question :-P |
| 15:05.13 | mnicholson | i like ini style configs better, I find them easy to read and write |
| 15:05.26 | oej | pabelanger: and error messages could be more useful! |
| 15:08.41 | tzafrir_laptop | leifmadsen, why bother having all of those names explicitly, and not use some #include foo/*.conf ? |
| 15:09.03 | leifmadsen | because it's more obvious what you're including? |
| 15:09.52 | tzafrir_laptop | e.g. , in sip.conf: #include confs/sip_*.conf |
| 15:10.01 | *** join/#asterisk-dev frd91gt (~frd91gt@209-124-48-194.static.123.net) |
| 15:10.15 | tzafrir_laptop | Where general would be: sip_00general.conf |
| 15:10.53 | tzafrir_laptop | Any other file interested in adding stuff to [general] would use [general](+) explicitly |
| 15:11.23 | tzafrir_laptop | This avoids the need of explicit ordering |
| 15:11.30 | leifmadsen | interesting |
| 15:11.41 | leifmadsen | pabelanger: thoughts? |
| 15:14.10 | pabelanger | leifmadsen: not sure, would have to see it in action. Never thought of it that way |
| 15:14.26 | leifmadsen | ya |
| 15:14.42 | leifmadsen | well it's just a numbered list of files with everything included |
| 15:14.47 | leifmadsen | not much to see in action :) |
| 15:16.08 | pabelanger | my brain is not working |
| 15:16.15 | pabelanger | can't picture it |
| 15:20.01 | oej | mnicholson: Sorry to be picky, but this doesn't seem correct |
| 15:20.02 | oej | #define DEFAULT_STORE_SIP_CAUSE FALSE /*!< Store HASH(SIP_CAUSE,<channel name>) for channels by default */ |
| 15:20.13 | mnicholson | oej, fixing |
| 15:20.15 | oej | If it's FALSE; it is not on by default, right. |
| 15:20.17 | oej | : -) |
| 15:21.40 | oej | Evening, folks. Logging off. |
| 15:37.15 | *** join/#asterisk-dev irroot (~irroot@197.173.101.201) |
| 15:46.21 | kpfleming | leifmadsen: pabelanger: can one of you guys take on the task of updating the Commit Messages page on the wiki? that would be most helpful. |
| 15:47.28 | leifmadsen | I don't know what the new format is |
| 15:47.36 | leifmadsen | or rather, what needs updating? |
| 15:47.54 | kpfleming | the format has not changed.. we just don't have a template generator for it now |
| 15:48.12 | kpfleming | but the updates needed are that it should include public JIRA issue numbers instead of Mantis issue numbers |
| 15:48.35 | kpfleming | and also the comments i just posted on the -dev list about ensuring that all commits related to an issue include the issue number(s) in the commit message, not just the one intended to close it |
| 15:48.45 | leifmadsen | it appears as though it already is like that.... |
| 15:48.54 | kpfleming | ahh... i failed to look |
| 15:48.56 | kpfleming | sorry :-( |
| 15:49.06 | leifmadsen | that's why I'm thoroughly confused :) |
| 15:49.08 | kpfleming | then we need to start pestering people to follow the rules |
| 15:49.13 | leifmadsen | RULEZ! |
| 15:49.17 | leifmadsen | (the rule) |
| 15:49.21 | leifmadsen | they* |
| 15:49.25 | leifmadsen | fails and walks away |
| 15:49.47 | pabelanger | Is there not a flag for 'svn commit' to have it use a template file? |
| 15:49.53 | kpfleming | no |
| 15:50.00 | pabelanger | :( |
| 15:50.07 | kpfleming | you'd have to just read it in to your editor |
| 15:50.12 | kpfleming | which is still pretty darn easy |
| 15:51.19 | leifmadsen | extra steps make people sad |
| 16:11.04 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:56.47 | russellb | i started a new commit message template script, i think it's in repotools |
| 16:57.07 | russellb | got the easy stuff, the harder stuff was listing who helped test it, and providing you with a list of patches and patch metadata |
| 17:06.45 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-148-150.bvtn.or.frontiernet.net) |
| 17:14.39 | tzafrir_laptop | http://kernel.org/doc/Documentation/SubmittingPatches - the kernel uses slightly different tags: |
| 17:15.21 | tzafrir_laptop | "Reported-by" , "Tested-by", Reviewed-by" (that is: separated by a dash, not a space) |
| 17:16.16 | tzafrir_laptop | If the space-separated ones are not already in use, maybe revert to the dash-separated ones |
| 17:16.43 | russellb | could be changed, those tags are what the mantis template used which we have used for a few years |
| 17:19.45 | sruffell | tzafrir_laptop: have you seen the thread in Internal-reference-ID? http://thread.gmane.org/gmane.linux.kernel/1173411 I think that's a good idea tooâ¦. |
| 17:20.09 | sruffell | s/thread in/thread on/ |
| 17:26.06 | tzafrir_laptop | yeah, that would be handy |
| 17:54.36 | kpfleming | look at all the fancy patches being committed to squash bugs |
| 18:22.02 | *** join/#asterisk-dev fenlander (~fenlander@82.152.81.57) |
| 18:24.23 | leifmadsen | +1 |
| 18:28.37 | kpfleming | who would use that? |
| 18:58.28 | *** join/#asterisk-dev Corydon76-home (three@c-69-137-80-31.hsd1.tn.comcast.net) |
| 18:58.28 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 19:02.54 | *** join/#asterisk-dev mickecarlsson (~Micke@h10n3c1o1101.bredband.skanova.com) |
| 19:22.39 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 19:22.39 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:23.28 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-128-145.bvtn.or.frontiernet.net) |
| 19:30.50 | *** part/#asterisk-dev frd91gt (~frd91gt@209-124-48-194.static.123.net) |
| 19:44.45 | *** join/#asterisk-dev oej (~olle@195.41.130.3) |
| 19:44.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:49.33 | Kobaz | mm |
| 19:49.35 | Kobaz | pokes JunK-Y |
| 20:35.55 | *** join/#asterisk-dev oej (~olle@195.41.130.3) |
| 20:35.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:45.51 | pabelanger | russellb: doh! |
| 20:47.55 | russellb | pabelanger: winning! |
| 20:57.07 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-128-145.bvtn.or.frontiernet.net) |
| 21:01.47 | pabelanger | russellb: winning indeed, thanks. |
| 21:02.05 | pabelanger | BTW: see mjordan patch on reviewboard for testsuite events. Pretty cool idea |
| 21:24.13 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 21:24.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:04.19 | otherwiseguy | kobaz: have you had a chance to try the new timbered patch? |
| 22:04.56 | otherwiseguy | Kobaz: silly capitilization |
| 22:15.38 | JunK-Y | pokes back Kobaz ! |
| 22:37.58 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 22:37.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:44.47 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-nhjpkmmlnpxkktwj) |
| 22:53.17 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 22:53.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:03.40 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 23:03.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:16.44 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 23:16.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |