| 00:19.23 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 00:50.30 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 01:29.35 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 01:46.52 | *** part/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 01:50.43 | *** join/#asterisk-dev Mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 01:50.43 | *** mode/#asterisk-dev [+o Mog] by ChanServ |
| 01:54.05 | mvanbaak | I realy should go to bed |
| 01:54.09 | mvanbaak | Mon Mar 16 02:53:54 CET 2009 |
| 01:55.10 | snuff-work | mm.. bad way to start monday morning ;) |
| 01:55.21 | mvanbaak | yup |
| 01:55.35 | mvanbaak | specially cause I'm finishing the bottle of vino at the moment |
| 02:09.00 | mvanbaak | I'm off |
| 02:48.00 | *** join/#asterisk-dev pmhaddad (n=pmhaddad@24-247-41-171.dhcp.mrqt.mi.charter.com) |
| 03:19.23 | *** join/#asterisk-dev pmhaddad (n=pmhaddad@24-247-41-171.dhcp.mrqt.mi.charter.com) |
| 03:19.29 | jtodd-hslfbldg | Here's a question... |
| 03:19.47 | jtodd | I've got someone who wants to do some steganographic work with Asterisk, inserting data into the audio stream. |
| 03:20.05 | snuff-work | mm.. |
| 03:20.20 | jtodd | I'd like to point them in the right direction to do this in a generic way - i.e.: not tied to any particular channel type, or data delivery method. |
| 03:20.45 | jtodd | To what structures would I point them on their first foray into Asterisk so that they would be manipulating the audio in a non-channel-specific way? |
| 03:21.18 | jtodd | This is "first advice" to someone who will hopefully be joining the IRC channel later, but I can't guarantee that they'll do anything other than just take the source and start coding without further consultation. |
| 03:21.43 | snuff-work | mm.. my only guess.. is an audiohook.. |
| 03:22.49 | jtodd | OK. I don't know enough about the audiohook.c stuff - is it a pluggable architecture with any examples, or would it require diddling with audiohook.c? |
| 03:23.26 | snuff-work | its pluggable from what i remember.. |
| 03:24.57 | snuff-work | i'm pretty sure app_confbridge uses audiohooks |
| 03:25.08 | jtodd | OK, so if I pointed them at http://www.asterisk.org/doxygen/trunk/structast__audiohook.html that would be a decent start? |
| 03:26.52 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 03:29.12 | snuff-work | jtodd: i can't think of a specific example other than app_confbridge |
| 03:30.20 | jtodd | OK, thanks. That's a good start. |
| 03:30.34 | snuff-work | ;) |
| 03:31.18 | jtodd | I think it would be pretty cool to move audio across any channel type and have it include low-speed data that's been stuffed into waveform modifications. |
| 03:32.04 | jtodd | There are a huge number of possibilities there, not just for moving data, but moving signaling. |
| 03:32.18 | jtodd | Anyway, it remains to be seen if they're serious about the project, but I'd like to encourage them. |
| 03:33.02 | jtodd | actually, app_jack.c should hook to it as well. |
| 03:33.24 | jtodd | Though I still haven't seen any use of app_jack to do cool stuff like voice disguise. I keep hoping someone will do an example... |
| 03:33.29 | snuff-work | ah yes.. app_jack might also be good |
| 04:01.30 | *** join/#asterisk-dev kerframil (n=kerframi@gentoo/user/kerframil) |
| 04:25.13 | *** join/#asterisk-dev CunningPike (n=arodgers@S01060014bf81366b.vc.shawcable.net) |
| 05:20.40 | *** part/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 05:51.37 | *** join/#asterisk-dev fiddur (i=fiddur@c042.rit.se) |
| 05:54.12 | *** join/#asterisk-dev ctooley (n=ctooley@mo-71-0-218-176.dhcp.embarqhsd.net) |
| 05:54.12 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 06:40.24 | mvanbaak | mornin all |
| 06:48.11 | snuff-work | feel ok? |
| 06:49.41 | mvanbaak | yeah, not too bad |
| 06:50.02 | mvanbaak | but I'm not going to bed that late anymore when I have to get up early |
| 08:11.48 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:11.43 | *** part/#asterisk-dev frawd (n=francois@14.Red-88-0-114.dynamicIP.rima-tde.net) |
| 09:39.17 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 10:22.39 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 10:22.39 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:23.18 | *** join/#asterisk-dev jnemeth (n=Miranda@S01060000c00d787b.gv.shawcable.net) |
| 10:24.45 | jnemeth | Hi. |
| 10:25.45 | jnemeth | I'm wondering if any thought has been given to systems with 64-bit time_t. In particular, 32-bit systems that have a 64-bit time_t? |
| 10:57.44 | snuff-home | mm doubtful |
| 11:07.08 | *** join/#asterisk-dev puzzled_ (n=patrick@puzzled.xs4all.nl) |
| 11:09.05 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 11:17.27 | *** join/#asterisk-dev DarkRift (n=dark@65.92.251.122) |
| 11:30.26 | *** join/#asterisk-dev Mr_BOnD_007 (i=Mr_BOnD_@119.160.199.6) |
| 11:49.23 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:49.23 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:53.08 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:53.08 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:54.16 | tzanger | jnemeth: do you forsee a problem? |
| 11:57.57 | *** join/#asterisk-dev Dovid (n=annon@tony09-121-90.inter.net.il) |
| 11:58.06 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:21.03 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:21.03 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:33.47 | *** join/#asterisk-dev lbt (n=david@78.32.229.233) |
| 12:36.41 | *** part/#asterisk-dev lbt (n=david@78.32.229.233) |
| 12:45.07 | tzafrir_laptop | Control Payback would be a nice feature |
| 12:49.24 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 12:55.45 | *** join/#asterisk-dev jjshoe (n=jjshoe@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 12:59.46 | jjshoe | is there an op up yet? |
| 13:01.49 | lmadsen | perhaps |
| 13:02.30 | jjshoe | lmadsen check #asterisk |
| 13:02.33 | jjshoe | nice little on join spammer |
| 13:04.12 | *** join/#asterisk-dev schmooze_tony (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 13:22.53 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 13:31.43 | *** join/#asterisk-dev juanjoc (n=juanjoc@200.69.219.113) |
| 13:44.26 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 14:06.31 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:06.31 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:16.02 | *** join/#asterisk-dev moy (n=chatzill@74.12.124.89) |
| 14:18.23 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:25.48 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@ool-4573c205.dyn.optonline.net) |
| 14:25.48 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 14:32.46 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 15:01.17 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 15:01.19 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 15:02.19 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:02.19 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:07.37 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:07.37 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:08.34 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:08.34 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:28.35 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:28.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:32.35 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:42.46 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 15:45.28 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 15:54.49 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:54.49 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 15:56.55 | *** join/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-4f4556e2cdfbff88) |
| 15:58.07 | Corydon76-lap | dbrooks: yay! |
| 15:58.18 | *** join/#asterisk-dev twisted (n=twisted@router.asteriasgi.com) |
| 15:58.18 | *** mode/#asterisk-dev [+o twisted] by ChanServ |
| 15:58.26 | twisted | wheeee |
| 15:58.40 | Corydon76-lap | hugs twisted |
| 15:58.52 | dbrooks | yay! |
| 15:58.53 | twisted | anyone in here happen to know where exactly we deal with the raw HDLC data on the d-channel of the PRI? |
| 15:59.05 | tzanger | "the raw HDLC data" ? |
| 15:59.12 | tzanger | as in what reads the HDLC frames and makes sense of it for PRI? |
| 15:59.14 | twisted | yeah... to parse it out into actual messages |
| 15:59.18 | twisted | yes |
| 15:59.30 | tzanger | that would be libpri I would imagine |
| 15:59.32 | Corydon76-lap | twisted: the messages are read in chan_dahdi and interpreted in libpri |
| 15:59.45 | twisted | see, that's what I was thinking, I'm just having a hard time actually finding the code that handles it |
| 16:00.09 | Corydon76-lap | It's an ioctl in chan_dahdi that reads it from the kernel |
| 16:01.10 | twisted | ahh okay... my hungoverdness didn't think about getting it from the kernel |
| 16:02.17 | twisted | in case you were wondering, I'm going to be working on my own messaging protocol over the HDLC channel |
| 16:02.31 | twisted | but I'm stuck on finding where we determine what type of message we're getting |
| 16:02.42 | twisted | (and actually getting it from) |
| 16:03.15 | Corydon76-lap | twisted: it's based entirely upon the channel type configured in chan_dahdi.conf |
| 16:03.39 | twisted | well of course... but we have to know what the raw data looks like to interpret it |
| 16:03.40 | Corydon76-lap | Or really, from the kernel |
| 16:04.03 | Corydon76-lap | No, I meant that there are multiple types that are all essentially HDLC |
| 16:04.24 | Corydon76-lap | Just one of them is assumed to be PRI |
| 16:04.55 | Corydon76-lap | and only the 24th channel (or 16th, on an E1) |
| 16:05.04 | Corydon76-lap | unless channel groups are defined |
| 16:05.21 | *** join/#asterisk-dev otherwiseguy (n=otherwis@cpe-72-128-38-41.kc.res.rr.com) |
| 16:05.55 | tzafrir_laptop | M13897 |
| 16:05.55 | twisted | right, but we still have to handle the raw HDLC data to handle it properly |
| 16:06.00 | MuffinMan | [confirmed] [DAHDI-linux] wcb4xxp 0013897: [patch] Support for generic HFC-4S cards reported by tzafrir (Karma: +120.00) http://bugs.digium.com/view.php?id=13897 |
| 16:06.02 | Corydon76-lap | There's basically a number of conditions that all have to apply for a channel to be interpreted as a PRI D channel |
| 16:06.11 | Corydon76-lap | Right |
| 16:06.17 | twisted | which is what i'm concerned with |
| 16:06.18 | twisted | :P |
| 16:06.38 | tzafrir_laptop | can anybody with a B410P card check that my latest patch there doesn't break it? |
| 16:07.01 | twisted | i'm dealing low-level |
| 16:07.03 | Corydon76-lap | If you're talking about an HDLC channel that needs to be interpeted some other way, I would introduce another kernel constant for the channel to be configured as |
| 16:07.04 | *** join/#asterisk-dev blargman_ (n=blargman@12.234.16.130) |
| 16:07.15 | twisted | well, we're still talking PRI over it |
| 16:07.27 | twisted | but I need to intercept messages that don't fit q921 or q931 and parse them |
| 16:07.27 | Corydon76-lap | Different switchtype, perhaps? |
| 16:07.35 | Corydon76-lap | Ah |
| 16:07.42 | kpfleming | your code will be on both ends of the link? |
| 16:07.48 | twisted | kp: yes |
| 16:07.54 | twisted | kp: long time no see, btw :) |
| 16:08.03 | kpfleming | yep, i thought about that a few days ago |
| 16:08.06 | kpfleming | very long time |
| 16:08.13 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 16:09.18 | twisted | but yeah... short of writing my own HDLC driver and loading zaptel against it, I wanted to use the existing code and pull out messages on an as-needed basis |
| 16:09.26 | tzafrir_laptop | any idea how to get that stream from the D channel into something that wireshark can read? |
| 16:10.12 | Corydon76-lap | twisted: I don't think there's really any driver in the kernel with respect to HDLC |
| 16:10.27 | Corydon76-lap | twisted: the data is simply passed up to userland to interpret |
| 16:10.32 | twisted | right |
| 16:10.54 | twisted | but rather than intercept it BEFORE it gets there, I'm trying to figure out how to get at it where we already handle it |
| 16:11.14 | kpfleming | that would be in the pri_dchannel() function in chan_dahdi.c |
| 16:11.48 | Corydon76-lap | So you're basically extending the set of commands |
| 16:12.01 | twisted | corydon: "basically" yes ;) |
| 16:12.04 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 16:12.30 | Corydon76-lap | There's a table that is installed in libpri that contains the command structure. It shouldn't be too difficult to provide an alternate |
| 16:12.39 | twisted | kp: ahh... hadn't gotten that far down in the code yet :) |
| 16:12.48 | tzafrir_laptop | aren't there devices along the way that should be able to understand those commands? |
| 16:12.58 | twisted | i know that much.. I've already had to hack it for out of sequence frames coming from this antiquated hardware |
| 16:12.58 | tzafrir_laptop | Or is it all end-to-end? |
| 16:13.14 | twisted | it's end to end |
| 16:13.49 | twisted | I remain in the control path throughout the entire length... kinda like a b2b, but over an existing data link |
| 16:14.07 | twisted | since the other device doesn't support any other method of data linkage |
| 16:14.34 | *** join/#asterisk-dev HubguruJR (n=jrichard@mail.ntegratedsolutions.com) |
| 16:15.20 | twisted | the only logical method of passing data between the two endpoints is to use an existing path.. |
| 16:15.43 | twisted | because it'd cost bookoos of $$ for my customer to develop and install ethernet or any other methods |
| 16:15.46 | Corydon76-lap | twisted: take a look at "struct ie ies[]" in q931.c, line 2187 |
| 16:15.57 | eliel | russellb: Good luck with the application to gsoc, do you have the template for the student? |
| 16:16.12 | kpfleming | Corydon76-dig: that's way too high a level, that's IEs in Q.931 |
| 16:16.18 | Corydon76-lap | twisted: basically, you want to add additional IEs to that structure |
| 16:16.20 | twisted | yeah, corydon, that was my first idea was to expand on q931, but the customer wants to go low-level |
| 16:16.21 | russellb | eliel: I don't have it handy. It was part of the application, and I can't view the application anymore |
| 16:16.29 | Corydon76-lap | twisted: ouch |
| 16:16.39 | kpfleming | twisted: you'll need to look at pri_check_event() in libpri, which reads from the D-channel fd and parses the HDLC frames |
| 16:16.44 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 16:16.47 | twisted | it's easier for them to deal with raw data (start bit|data|stop bit) |
| 16:16.54 | Corydon76-lap | twisted: it seems like it would be easier simply to extend into unused IEs within the Q.931 structure |
| 16:17.21 | twisted | corydon: yes, it would if we were dealing with code on the other end that was newer than 1984 |
| 16:17.27 | Corydon76-lap | You don't have to worry about encoding at that point... it's just a bitstream, really |
| 16:17.29 | twisted | :P |
| 16:17.30 | kpfleming | only if their commands were part of call setup/teardown |
| 16:17.58 | eliel | russellb: np |
| 16:18.11 | Corydon76-lap | kpfleming: there aren't other informational elements? |
| 16:18.19 | twisted | kp: hmm... so pri_dchannel() in dahdi, and pri_check_event in libpri... |
| 16:18.21 | Corydon76-lap | kpfleming: like piggybacking on aoc? |
| 16:18.24 | twisted | there ARE other IE's |
| 16:18.39 | twisted | but AOC is part of call messaging |
| 16:18.42 | kpfleming | yes, but IEs are part of Q.931 commands. SETUP, FACILITY, RELEASE, etc. |
| 16:18.47 | Corydon76-lap | Excuse me, not IEs, but commands |
| 16:18.51 | kpfleming | no idea |
| 16:19.15 | twisted | well, there are normal messages, like reciever ready, RESET, etc |
| 16:19.26 | kpfleming | that's Q.921 |
| 16:19.30 | twisted | right |
| 16:19.34 | jsmith | There are also user-defined IEs, right? |
| 16:19.39 | jsmith | Could you just use those? |
| 16:19.40 | kpfleming | yes |
| 16:19.48 | kpfleming | what command are you going to attach them to? |
| 16:19.57 | Corydon76-lap | jsmith: yeah, but we're talking about a command set on which to attach the IEs |
| 16:20.00 | jsmith | func_chan? |
| 16:20.03 | twisted | well, the're not really "commands" so to speak |
| 16:20.06 | twisted | just raw data packets |
| 16:20.10 | twisted | like |
| 16:20.17 | kpfleming | but are they associated with existing calls? |
| 16:20.25 | jsmith | Same way we do with variables over IAX? |
| 16:20.32 | twisted | (start bit|004F2933270F|stop bit) |
| 16:20.37 | twisted | ( we haven't decided on the bits yet) |
| 16:20.38 | twisted | kp: nope. |
| 16:20.56 | kpfleming | then yeah, doing it over Q.931 would be very hard |
| 16:21.07 | twisted | exactly why we're going low level :) |
| 16:21.42 | Corydon76-lap | You could do USER INFORMATION commands |
| 16:21.55 | twisted | without breaking my NDA with this customer, basically the pri "client" side is going to be sending me raw data regarding provisioning and logging, and I'm going to be dealing with it based on the first bit after the start bit |
| 16:22.05 | jsmith | Corydon76-dig: Those are tied to a particular call, as I understand it. |
| 16:22.12 | twisted | and ACKing the messages by checksumming |
| 16:22.17 | kpfleming | yes. Q.931 will not work for this application |
| 16:22.33 | kpfleming | you'd need to send HDLC frames that are marked as 'not Q.921', if that is possible |
| 16:22.50 | twisted | well, they will be marked... bitwise |
| 16:22.50 | kpfleming | there is no need to use start bit/stop bit, this is not a bit-oriented channel |
| 16:23.08 | kpfleming | HDLC is frames, always |
| 16:24.07 | twisted | okay, then I'm just using the wrong terminology |
| 16:24.33 | kpfleming | right |
| 16:24.38 | HubguruJR | Corydon76-lap: thanks for comment on func realtime, made sense, still would like to see the original app realtime behavior though. |
| 16:24.55 | kpfleming | if you are doing this over a D channel, everything will be in frames, with size specified, checksums (FCS), etc. |
| 16:25.24 | twisted | oh yeah... that's right... no need to calc my own checksums..haha |
| 16:25.29 | kpfleming | so presumably there is some sort of header on the frame that identifies what it contains, unelss Q.921 is just assumed |
| 16:25.33 | Corydon76-lap | HubguruJR: what, polluting the channel namespace? |
| 16:25.45 | kpfleming | if Q.921 is assumed, then you can't use anything else, you'll have to work on top of Q.921 |
| 16:25.49 | twisted | yeah, the "marker bit" in the wrong terminology... |
| 16:26.03 | twisted | basically the message identifier |
| 16:26.17 | HubguruJR | no, just thanking you for your help. that's all |
| 16:26.43 | Corydon76-lap | HubguruJR: I really try to get away from pollution of namespace, as it could lead to unexpected results... |
| 16:27.15 | twisted | but I think I might have some good info to go on to start working on this now... thanks kp, corydon, et al. |
| 16:27.27 | jsmith | twisted: If they didn't need to be sent reliably, it looks like you *might* be able to send them as "unnumbered information" frames in Q.921 |
| 16:27.35 | twisted | don't be surprised if I pop back in going "AAAHHHHH" lol |
| 16:27.40 | Corydon76-lap | HubguruJR: the exact scenario is adding a column that negates a column from another query, which could destroy your dialplan logic. By using separate containers, we can avoid that |
| 16:27.47 | twisted | jsmith: but they do, that's part of the issue ;P |
| 16:28.01 | Corydon76-lap | s/containers/result containers/ |
| 16:28.40 | jsmith | twisted: Gotcha... sounds like they'd have to be some sort of I (information) frames that don't conflict with other Q.921 messaging. |
| 16:28.56 | HubguruJR | Corydon76-lap: yea, I'm ok with that, just miss the simplistic app, but can certainly deal with the progress in the func |
| 16:29.20 | Corydon76-lap | HubguruJR: hence, REALTIME_HASH() |
| 16:30.51 | Corydon76-lap | tzanger: is debuggery the opposite of buggary? |
| 16:31.35 | Corydon76-lap | tzanger: ;-) |
| 16:31.49 | tzanger | hahahaha |
| 16:31.55 | tzanger | buggery is in, debuggery is out |
| 16:33.15 | kpfleming | tzafrir_laptop: please merge your external module branch into trunk if it works for you... i have some other changes to make in the ecdis/ec_state area and don't want to conflict with your changes |
| 17:05.04 | *** join/#asterisk-dev mosty (n=mosty@213-66-224-163-no22.tbcn.telia.com) |
| 17:30.47 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 17:40.48 | *** part/#asterisk-dev Mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 17:46.06 | *** part/#asterisk-dev HubguruJR (n=jrichard@mail.ntegratedsolutions.com) |
| 17:46.43 | tzafrir_laptop | kpfleming, sorry it took me so long. I was busy with something else. |
| 17:47.08 | tzafrir_laptop | I want to still take a second look at the dahdi_config one. Doe it also conflict with what you do? |
| 17:53.21 | *** join/#asterisk-dev albertoandrade (n=albertoa@200.195.162.210) |
| 17:56.56 | *** join/#asterisk-dev Mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 17:56.56 | *** mode/#asterisk-dev [+o Mog] by ChanServ |
| 17:58.19 | *** join/#asterisk-dev AdamWest (n=Leif@CPE00183957a418-CM0018c0b39444.cpe.net.cable.rogers.com) |
| 17:59.44 | kpfleming | tzafrir_laptop: i don't remember what that one is, but i'll look after the meeting i'm headed into |
| 18:07.22 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 18:55.01 | *** join/#asterisk-dev jnemeth (n=Miranda@S01060000c00d787b.gv.shawcable.net) |
| 18:55.30 | jnemeth | tzanger? |
| 18:56.27 | tzanger | yes? |
| 18:57.27 | seanbright | john boy? |
| 18:58.10 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 18:58.11 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 18:58.43 | jnemeth | you asked me earlier if I foresee a problem with * on 32-bit systems that have a 64-bit time_t... empirical evidence says yes... NetBSD -current recently went to 64-bit time_t on all platforms... I had * 1.6.0.6 running nicely before my last upgrade... I recompiled it immediately after the upgrade and now * blows up... |
| 18:59.45 | tzanger | jnemeth: hmm, you'd have to take a look at anything involving jiffies in dahdi and see if it's using the right typedef |
| 19:01.25 | seanbright | i'm sure there are places other than dahdi where we assume a 32 bit time |
| 19:03.24 | jnemeth | I haven't even started porting DAHDI... that had percolated to the top of the list, but now just getting * to run has taken over the top of the list... |
| 19:03.59 | seanbright | are you getting compilation failures or runtime? |
| 19:04.13 | jnemeth | I just discovered main/stdtime, which looks to be lots of fun... |
| 19:04.54 | jnemeth | crashes at runtime... there were compilation warnings about using time_t with %ld, but I've taken care of all those... |
| 19:05.04 | seanbright | fun. |
| 19:05.39 | seanbright | well the solution is simple |
| 19:05.44 | seanbright | we no longer support netbsd |
| 19:05.45 | seanbright | :P |
| 19:05.47 | seanbright | heh |
| 19:06.12 | jnemeth | btw, on another issue, do you want patches for OS support (I have a bunch of patches for DragonflyBSD), or should those just wait for more autoconfisication? |
| 19:06.41 | jnemeth | you never truely supported anything other then linux, so that's not a change... :P |
| 19:07.25 | seanbright | just put what you got in the bug tracker for evaluation |
| 19:07.59 | seanbright | runs off |
| 19:09.12 | jnemeth | hmm... more fun with the bug tracker... |
| 19:09.26 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 19:09.26 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 19:10.35 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:10.35 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 19:30.14 | snuff-home | jnemeth: maybe if you put up ur solution it may prompt someone to make the 'autoconf' checks instead of code hacks ;) |
| 19:43.17 | kpfleming | tzafrir_laptop: thanks you can remove your branches now :-) |
| 19:46.16 | eliel | someone knows about a tree structure implementation using the BSD license or another license asterisk compatible? |
| 19:46.45 | russellb | libxml2? :-) |
| 19:47.58 | eliel | russellb: yes, maybe i can use it... thanks for doing me think twice about what i have asked :) |
| 19:48.35 | seanbright | yeah, why use a simple btree implemenation when you can use something with a lot more overhead? |
| 19:48.38 | seanbright | :P |
| 19:48.47 | seanbright | <-- troll |
| 19:49.10 | russellb | seanbright: do you even know why he's asking? |
| 19:49.15 | seanbright | yes |
| 19:49.24 | seanbright | i know EXACTLY why he's asking |
| 19:49.25 | russellb | oh, ... well ... |
| 19:49.31 | seanbright | (actually i have no idea) |
| 19:49.35 | russellb | pwnt |
| 19:49.45 | seanbright | or something |
| 19:50.15 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 19:56.48 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 19:58.00 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 20:10.49 | *** join/#asterisk-dev shido6 (n=shido6@96-28-34-156.dhcp.insightbb.com) |
| 20:20.28 | *** join/#asterisk-dev pmhaddad-work (n=pmhaddad@141.219.87.43) |
| 20:30.15 | *** join/#asterisk-dev CunningPike_ (n=arodgers@204.239.10.119) |
| 20:31.08 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 20:36.22 | russellb | moy: ping |
| 20:36.29 | russellb | commit asterisk 182355 |
| 20:36.33 | MuffinMan | [182355] Committed by russell on 2009-03-16T20:35:58.222361Z: Add MFC/R2 support for chan_dahdi. |
| 20:36.33 | MuffinMan | .. |
| 20:36.33 | MuffinMan | ..This commit introduces official support for R2 signaling in chan_dahdi. The |
| 20:36.33 | MuffinMan | ..modifications to chan_dahdi, and the supporting library, LibOpenR2, were both |
| 20:36.34 | MuffinMan | ..written by Moises Silva. |
| 20:36.36 | MuffinMan | .. |
| 20:36.38 | MuffinMan | ..Many users are using this code, or a variant of it, in Asterisk 1.2, 1.4 and 1.6 |
| 20:36.41 | MuffinMan | ..in Brazil, México and Argentina. An unknown number of users (but at least 1) |
| 20:36.44 | MuffinMan | ..are using it in each of the following countries: Colombia, Nepal, Thailand, |
| 20:36.47 | MuffinMan | ..Venezuela, Perú, and probably others. |
| 20:36.49 | MuffinMan | .. |
| 20:36.51 | MuffinMan | ..To use this code, LibOpenR2 must be installed from http://www.libopenr2.org/. |
| 20:36.54 | MuffinMan | ..Information about configuration can be found in configs/chan_dahdi.conf.sample. |
| 20:36.58 | MuffinMan | .. |
| 20:36.59 | MuffinMan | ..The code committed is the most up to date version, which was being maintained |
| 20:37.02 | MuffinMan | ..in svn/asterisk/team/moy/mfcr2/. |
| 20:37.05 | MuffinMan | .. |
| 20:37.07 | MuffinMan | ..I would also like to include a Thank You to the many others that tested this |
| 20:37.10 | MuffinMan | ..code beyond those listed in this commit message. These are the names that I |
| 20:37.12 | MuffinMan | ..could find in the mantis issue. |
| 20:37.15 | MuffinMan | .. |
| 20:37.18 | MuffinMan | ..(closes issue #12509) |
| 20:37.20 | MuffinMan | ..Reported by: moy |
| 20:37.22 | MuffinMan | ..Patches: |
| 20:37.24 | MuffinMan | .. chan_zap-mfr2.patch uploaded by moy (license 222) |
| 20:37.27 | MuffinMan | ..Tested by: moy, korihor, viniciusfontes, Skarmeth, loloski, asbestoshead, titogarrido, heliocoelhojr, konsultex, ncorrare, ecarruda, rtorresduque, PTorres, ychen |
| 20:37.30 | MuffinMan | .. |
| 20:37.33 | MuffinMan | ..Review: http://reviewboard.digium.com/r/40/ |
| 20:37.35 | MuffinMan | .. |
| 20:37.37 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=182355 |
| 20:41.55 | Qwell | zomfg! |
| 20:49.42 | moy | omg :) |
| 20:49.54 | moy | R2 finally in trunk, thanks russellb ! |
| 20:50.02 | russellb | Thank _You_ :-) |
| 20:51.20 | *** join/#asterisk-dev leif[mobile] (n=leifmads@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:51.20 | *** mode/#asterisk-dev [+o leif[mobile]] by ChanServ |
| 20:53.31 | Qwell | who's gonna teach moy the secret handshake now? |
| 20:54.38 | russellb | Qwell: you! |
| 20:54.47 | Qwell | You guys still haven't taught it to me! |
| 20:56.23 | putnopvut | The secret handshake isn't really all that secret. It's just a regular handshake, but you have to wink when you're done. |
| 21:11.21 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 21:15.10 | mvanbaak | gheh, if you know the secret handshake you get this for free: http://www.worldwidefred.com/hacked.htm |
| 21:17.38 | mvanbaak | Qwell: there's no ticket open for wedhorn's rewrite |
| 21:17.59 | Qwell | mvanbaak: k |
| 21:20.15 | mvanbaak | we should prolly open one |
| 21:20.21 | mvanbaak | I'll ask wedhorn |
| 21:30.24 | tzafrir_laptop | M14528 |
| 21:30.26 | MuffinMan | [new] [Asterisk] Channels/chan_dahdi 0014528: chan_dahdi loses dialtone after some time after reboot reported by evandro (Karma: neutral) http://bugs.digium.com/view.php?id=14528 |
| 21:31.08 | tzafrir_laptop | at first glance this looks like zaptel (the driver) or some hardware / settings issue |
| 21:34.50 | mvanbaak | russellb: you here ? |
| 21:34.55 | russellb | nope! |
| 21:34.57 | russellb | i mean yes |
| 21:35.05 | mvanbaak | will try again later ;) |
| 21:35.29 | mvanbaak | ah, it's later |
| 21:35.32 | mvanbaak | russellb: you here ? |
| 21:35.34 | mvanbaak | ;) |
| 21:35.35 | russellb | yes! |
| 21:35.57 | mvanbaak | do you have any idea how many devs are running asterisk-trunk in production ? |
| 21:36.11 | russellb | 800 km of them |
| 21:36.36 | mvanbaak | k |
| 21:36.44 | russellb | (no clue) |
| 21:37.02 | mvanbaak | well, your message to asterisk-dev got me thinking |
| 21:37.12 | mvanbaak | about the release process |
| 21:37.18 | mvanbaak | yeah I know it's set |
| 21:37.22 | mvanbaak | but still |
| 21:38.27 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 21:38.40 | mvanbaak | I'm afraid it will become a mess soon. specially when trunk has the stuff for 1.6.3 or 1.6.4 |
| 21:39.07 | mvanbaak | bugfixes to trunk will then be merged to 1.6.0, 1.6.1, 1.6.2, 1.6.3 and 1.6.4 |
| 21:39.18 | russellb | nah, we'll only be maintaining a max of 3 branches |
| 21:39.19 | mvanbaak | this will become unmaintainable |
| 21:39.22 | russellb | once 1.6.3 is out, no more 1.6.0 |
| 21:39.35 | mvanbaak | and what about 1.4 ? |
| 21:39.42 | russellb | no plan for deprecating 1.4 yet |
| 21:39.53 | russellb | it is a burden, but it's sort of a compromise between developers and users |
| 21:40.05 | russellb | users still get feature frozen stuff they can rely on for an extended period of time |
| 21:40.09 | mvanbaak | so bugfixes should go into 1.4, then merged to trunk, then merged to 1.6.0, 1.6.1 and 1.6.2 |
| 21:40.11 | russellb | and we get to push out functionality quicker than in the past |
| 21:40.14 | russellb | yes |
| 21:41.12 | mvanbaak | ok |
| 21:41.26 | mvanbaak | other way of doing it: |
| 21:41.39 | mvanbaak | trunk is now unlocked for cool new stuff |
| 21:41.47 | mvanbaak | like the mr2 stuff you just merged |
| 21:41.57 | mvanbaak | how about we do this for 4 more months |
| 21:42.32 | mvanbaak | after that, lock the tree for new stuff and 'force' all the devs to run trunk into production to get rid of all the regressions/bugs |
| 21:42.48 | mvanbaak | branch new version and unlock tree again for new stuff |
| 21:43.00 | russellb | well, that's sort of the idea once we branch off ... we shake out bugs once we branch it off |
| 21:43.00 | mvanbaak | that way you have all the devs testing the new version |
| 21:43.13 | mvanbaak | yeah, but you still allow new stuff to go into trunk |
| 21:43.14 | russellb | like, file just now upgraded his PBX to 1.6.2 |
| 21:43.29 | mvanbaak | and as you know devs like to create new stuff before fixing bugs |
| 21:44.03 | mvanbaak | in my opinion all devs should run trunk in production. eat your own dogfood |
| 21:44.10 | russellb | sure, i agree |
| 21:44.15 | russellb | for those that have something called production |
| 21:44.17 | russellb | like me, I don't. |
| 21:44.19 | mvanbaak | getting rid of all the seperate 'production ready' branches |
| 21:44.37 | mvanbaak | russellb: digium's core pbx-en dont run trunk ? |
| 21:44.45 | russellb | HA, no. :-p |
| 21:44.52 | russellb | it used to, back in the good ol' days |
| 21:44.54 | mvanbaak | see, there's the first problem |
| 21:45.31 | mvanbaak | if 1.6.2 is released, we have 4 'production grade' versions |
| 21:45.33 | russellb | did you get bitten by a bad bug or something? |
| 21:45.38 | seanbright | will not be running trunk at work |
| 21:45.39 | mvanbaak | yup |
| 21:45.46 | seanbright | where actual money is involved |
| 21:45.47 | seanbright | heh |
| 21:45.49 | mvanbaak | more then once |
| 21:46.24 | russellb | well if it turns out we should only keep 2 1.6 branches or something, then that's fine |
| 21:46.32 | russellb | we're sort of playing this by ear a bit |
| 21:46.46 | mvanbaak | that's why I wanted to give my opinion |
| 21:46.48 | mvanbaak | :) |
| 21:47.02 | tzafrir_laptop | mvanbaak, I expect it to run Digium's latest supported product. Which may not necessarily be the SVN version |
| 21:47.15 | Corydon76-lap | I don't know if 1.6.0 goes away prior to 1.4 going away... right? |
| 21:47.40 | mvanbaak | Corydon76-lap: as I interpred stuff 1.6.0 will be gone before 1.4 |
| 21:47.54 | tzafrir_laptop | there are different kinds of dog foods to eat. Not only Asterisk from SVN |
| 21:47.59 | russellb | there has been no discussion about 1.4 going away anytime soon |
| 21:48.02 | mvanbaak | Corydon76-lap: like russell said. no plans to deprecate 1.4 but we are only going to support 3 1.6.X branches |
| 21:48.23 | Corydon76-lap | mvanbaak: I haven't made any assumptions; I'm just asking the question about which one would theoretically be discontinued first. |
| 21:48.35 | russellb | getting rid of 1.2 when we did pissed off so many people ... we have to listen to our user base |
| 21:49.27 | mvanbaak | any deprecation will piss off a lot of people |
| 21:49.30 | mvanbaak | believe me |
| 21:50.05 | seanbright | if 1.4.0 was rock-hard-stable, less people would have been pissed off |
| 21:50.09 | Corydon76-lap | I think our userbase wants us to support 35 release versions at the same time... or at least, support every released version forever... |
| 21:50.23 | seanbright | i think our user base wants consistently "good" releases |
| 21:50.45 | mvanbaak | I think the best way to do stuff is: get rid of 1.4 now that we have 1.6.0 and 1.6.1, and from now on support 2 versions |
| 21:50.46 | seanbright | the fact that people feel they have to wait for 1.4.20+ to migrate is not good |
| 21:51.19 | seanbright | plus it should all be in c++ |
| 21:51.24 | seanbright | or lisp |
| 21:51.38 | russellb | seanbright: yes, 1.4 quality was piss poor, and I have been trying to learn lessons from it |
| 21:51.42 | Corydon76-lap | seanbright: it's not Friday |
| 21:51.45 | mvanbaak | so if 1.6.2 is tagged we support 1.6.2 and 1.6.3 and development will go on in trunk for roughly 4 to 5 months, then we have a tree lock so only fixes should go in and all devs run trunk (including digium) so we can move forward real quick |
| 21:51.57 | mvanbaak | and create a new release every 6 months |
| 21:51.59 | russellb | so, things like, 1) trunk code quality _must_ be improved. So, stricter code review, with things like reviewboard (etc.) .. |
| 21:52.09 | seanbright | russellb: the lesson to learn is that our (the open source project's) QA sucks |
| 21:52.15 | russellb | 2) Not building up 2 years worth of development work before anyone tries it |
| 21:52.23 | russellb | seanbright: yes, and that. |
| 21:52.45 | russellb | which is why we now have 3) release candidates .. |
| 21:52.50 | russellb | so, we're improving in ways here and there. |
| 21:52.58 | seanbright | agreed. |
| 21:53.01 | seanbright | but |
| 21:53.06 | mvanbaak | so if 1.6.2 is tagged we support 1.6.2 and 1.6.3 <--- should be: so if 1.6.2 is tagged we support 1.6.1 and 1.6.2 |
| 21:53.14 | seanbright | i would run an RC of mutt |
| 21:53.18 | seanbright | i would not run an RC of asterisk |
| 21:53.49 | tzafrir_laptop | what's the expected time beyween major releses? |
| 21:53.55 | seanbright | the people who are running into the b |
| 21:53.57 | seanbright | grrr |
| 21:54.03 | Corydon76-lap | seanbright: to be fair, running an RC of Asterisk is more like running an RC of the Linux kernel. Massively more complex. |
| 21:54.07 | mvanbaak | tzafrir_laptop: 6 months |
| 21:54.23 | russellb | I was aiming for more like 3 |
| 21:54.27 | russellb | even though it hasn't happened in reality |
| 21:54.37 | mvanbaak | that's too much |
| 21:54.46 | seanbright | Corydon76-lap: i'm not shitting on asterisk, i'm just saying: mutt crashes on me, big deal. asterisk crashes on me, we don't make any money. |
| 21:54.46 | mvanbaak | ppl are not going to upgrade every 3 months |
| 21:54.53 | seanbright | so i'm not willing to take that risk |
| 21:55.05 | Corydon76-lap | seanbright: ah |
| 21:55.22 | mvanbaak | if we release a new major version every 6 months, and support the current stable + previous version ppl can run a version a year before running out of support |
| 21:55.30 | Corydon76-lap | seanbright: or I suppose the more apt comparison is to Apache or MySQL |
| 21:55.36 | tzafrir_laptop | people will need to upgrade every 3 cycles |
| 21:55.42 | mvanbaak | if "we" run our own dev version we will have a stable version all the time |
| 21:56.27 | mvanbaak | oh, and make sure the lock date for trunk is taken by suprise |
| 21:56.41 | seanbright | Corydon76-lap: asterisk is a lot more complex than either of those packages, imho. |
| 21:56.47 | mvanbaak | that way devs cannot slackoff and merge stuff that's not totally ready |
| 21:56.56 | mvanbaak | because they never know when stuff gets locked |
| 21:57.20 | seanbright | Corydon76-lap: if we _just_ did SIP, and released 1.8.whatever, i would probably throw it into production after a few days of testing |
| 21:57.27 | tzafrir_laptop | Asterisk is not more complex than the kernel. But the kernel has many more testers |
| 21:57.47 | mvanbaak | anywayz, this is just my view on stuff |
| 21:57.52 | seanbright | but it just feels like there are so many more things that can go wrong with asterisk |
| 21:58.05 | seanbright | and i <3 asterisk, as you know. |
| 21:58.29 | tzafrir_laptop | seanbright, you know too well many of the things that can go wrong |
| 21:58.54 | seanbright | i'm not sure how to take that |
| 21:58.54 | seanbright | :) |
| 21:59.56 | seanbright | 1.2 queues sucked, 1.4 chanspy sucked |
| 22:00.12 | seanbright | i haven't in stalled 1.6 yet, so i'll let you know what sucks when i install that :) |
| 22:00.16 | seanbright | installed* |
| 22:00.38 | seanbright | hopes it's not menuselect or cdr_tds |
| 22:00.43 | mvanbaak | seanbright: chan_skinny sucks in there ;) but that's not going to bite you I guess |
| 22:01.28 | seanbright | dahdi, chan_sip, cdr_tds, queues, chanspy |
| 22:01.32 | seanbright | that's basically all i need |
| 22:02.19 | tzafrir_laptop | So what do I do with my Asterisk 1.6.x server after 18 (or 9) monthes? Do we expect an upgrade procedure will work relatively well? |
| 22:03.05 | russellb | supposed to, I also intend to treat backwards compatibility as much more of a _requirement_ now than how we have treated it for the past few years |
| 22:03.11 | russellb | i.e., no more removing stuff just because we can |
| 22:06.04 | putnopvut | is happy to see that seanbright did not mention that 1.4 queues sucked |
| 22:06.31 | seanbright | i saw you standing in the corner |
| 22:06.58 | russellb | there are a number of things that sucked in 1.4 in early release |
| 22:07.07 | russellb | chanspy/mixmonitor was rewritten more than once |
| 22:07.09 | putnopvut | russellb: like chan_vacuum? |
| 22:07.12 | russellb | app_queue took a lot of work |
| 22:07.18 | russellb | chan_iax2 was a clusterf*@k |
| 22:07.39 | putnopvut | adding audiohooks to 1.4 was a sweet move |
| 22:07.43 | seanbright | no doubt |
| 22:07.58 | russellb | asterisk 1.4 still isn't perfect, but we've come a long way with stability there |
| 22:08.06 | russellb | stability is _critical_ with our project |
| 22:08.11 | russellb | more so than most others, i would say |
| 22:08.16 | seanbright | concurs |
| 22:08.22 | russellb | we have made over 3000 commits to the 1.4 branch. |
| 22:08.32 | russellb | that's quite a bit of dedication to a feature frozen release, i would say :-) |
| 22:08.48 | seanbright | but with our complexity, it's hard to be stable |
| 22:08.57 | putnopvut | yeah, I heard that. |
| 22:09.14 | putnopvut | What sucks is that some small change can cause a bug in something that one might think was completely unrelated. |
| 22:09.20 | seanbright | exactly |
| 22:09.21 | putnopvut | Take the broken call pickup in 1.4.22 |
| 22:09.33 | seanbright | takes it |
| 22:10.13 | *** join/#asterisk-dev tamiel (n=tamiel@ip-176.net-89-2-117.rev.numericable.fr) |
| 22:10.37 | russellb | someone needs to organize a community initiative for distributed testing of RCs as a way to get involved in the development community |
| 22:10.47 | russellb | hides |
| 22:11.13 | russellb | and on that note, time for me to run |
| 22:11.14 | mvanbaak | russellb: agreed |
| 22:11.30 | mvanbaak | have fun dude ! |
| 22:11.35 | mvanbaak | thanks for listening |
| 22:20.31 | eliel | what about using a test framework and start coding test cases for core functions |
| 22:21.07 | eliel | instead of doing some "test" cli commands, use a unit testing framework... |
| 22:22.10 | eliel | a lot of stuff could be tested in this way |
| 22:22.40 | putnopvut | eliel: russellb recently added a GSoC project idea that is similar to what you are talking about. |
| 22:22.49 | seanbright | are there good unit testing frameworks for C? |
| 22:22.55 | mvanbaak | still that's not a holy grale |
| 22:23.03 | seanbright | it's a start |
| 22:23.18 | eliel | putnopvut: the russellb idea was to re-invent a unit testing though... |
| 22:23.24 | mvanbaak | best start is if devs start running trunk |
| 22:23.29 | seanbright | ugh |
| 22:23.31 | mvanbaak | in production |
| 22:23.34 | seanbright | not practical |
| 22:23.51 | file | not all of the devs run Asterisk at home |
| 22:24.04 | seanbright | doesn't have a home phone |
| 22:24.12 | mvanbaak | file: like I asked russell: digium should run trunk |
| 22:24.37 | seanbright | mvanbaak: these are businesses |
| 22:25.18 | mvanbaak | seanbright: if trunk is that buggy, the 1.6 release created from it will be buggy, noone will run it in production, bugs wont be fixed, goto trunk-is-buggy |
| 22:25.25 | mvanbaak | so you never get out of it |
| 22:26.20 | seanbright | maybe i wasn't clear... |
| 22:26.22 | putnopvut | mvanbaak: you're leaving out some steps there. |
| 22:26.28 | seanbright | digium is a business |
| 22:26.39 | seanbright | buisness |
| 22:26.44 | seanbright | biz |
| 22:26.52 | mvanbaak | seanbright: yes ? |
| 22:27.06 | putnopvut | mvanbaak: It's not as if a 1.6 release is made directly from trunk. It's branched, has betas and rc's before being released. |
| 22:27.28 | putnopvut | So there are opportunities for stabilizing the release at that point. |
| 22:27.37 | putnopvut | s/that point/those points/ |
| 22:27.53 | seanbright | imagine you are a customer, calling into support because your phone system crashed, and while you are on the phone with the company that is supporting you, *their* phone system crashes |
| 22:27.56 | eliel | putnopvut: the problem is that if no one test those rc's we have the same problem... |
| 22:27.58 | mvanbaak | putnopvut: I know. but businesses are not running that for the same reasons they are not running trunk |
| 22:28.09 | putnopvut | eliel: yes, you are absolutely correct. |
| 22:28.27 | eliel | i am running asterisk 1.4.23.2 at work |
| 22:28.51 | seanbright | i am running 1.4.21 with some special seanbright magic |
| 22:28.56 | putnopvut | mvanbaak: yeah, unfortunately, unless something is listed as "stable" most businesses won't run it. |
| 22:28.57 | mvanbaak | ok, you all going to hate me for this |
| 22:28.58 | eliel | we have a callcenter of 600 agents, i don't have the assigned time to run tests against 1.6.x |
| 22:29.05 | mvanbaak | but please have a look at this: http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/ |
| 22:29.12 | seanbright | declines |
| 22:29.18 | putnopvut | mvanbaak: actually only seanbright will hate you for that. |
| 22:29.51 | seanbright | running trunk in production will not solve the stability or "buggy" issues |
| 22:29.51 | eliel | i am not going to implement 1.6 till 1.6.15 :) |
| 22:30.03 | seanbright | developing testing and QA procedures that we stick to will |
| 22:30.37 | seanbright | i nominate stevie_ramjet for that task |
| 22:30.41 | mvanbaak | the problem with QA is that only a small part of the devs are involved |
| 22:30.41 | seanbright | wherever he is |
| 22:31.01 | seanbright | mvanbaak: devs shouldn't be involved with QA at all, imho. |
| 22:31.04 | mvanbaak | while the process described there in the slides makes _ALL_ devs part of the QA team |
| 22:31.14 | seanbright | well, integration testing, yes. functional testing, no. |
| 22:31.22 | mvanbaak | seanbright: they should, because they are the ones that should fix stuff |
| 22:31.41 | stevie_ramjet | If you ask me, open source projects by nature are missing a development phase that any commercial project would have. |
| 22:31.42 | seanbright | they are involved in bug fixes, yes. but not in the actual testing. |
| 22:31.59 | stevie_ramjet | That's just a phase where no coding happens and developers do nothing but small-scale DVT and regression testing. |
| 22:32.08 | mvanbaak | seanbright: it think you get way better results if you involve them |
| 22:32.12 | mvanbaak | let me explain |
| 22:32.21 | mvanbaak | devs dont like the testing part |
| 22:32.25 | mvanbaak | they want to create new stuff |
| 22:32.31 | seanbright | it's not about not liking testing |
| 22:32.36 | mvanbaak | so if you make them part of the test-team as well |
| 22:32.46 | mvanbaak | they will produce better code before merging it into trunk |
| 22:32.56 | mvanbaak | because that way they know the test period will be short |
| 22:33.02 | mvanbaak | simply because there are no bugs |
| 22:33.18 | seanbright | i'm not sure i follow your logic |
| 22:33.48 | seanbright | developers have to be involved in testing to fix the bugs. |
| 22:33.50 | eliel | mvanbaak: it is hard for a developer to become a tester... s/he is trying to do so, all the time before commiting, and s/he fails and commit bugs for that reason... |
| 22:34.01 | mvanbaak | eliel: I know |
| 22:34.09 | seanbright | developers should not be involved in the actual testing. |
| 22:34.18 | seanbright | developers don't use the application like a user would. |
| 22:34.40 | seanbright | and developers implicitly know the "right way" to use the application |
| 22:34.51 | seanbright | they make lousy testers |
| 22:35.19 | mvanbaak | the test team should not be devs only |
| 22:35.31 | mvanbaak | but you _HAVE_ to add the devs to the testteam |
| 22:35.36 | seanbright | i think we're not going to see eye to eye on this one |
| 22:35.49 | mvanbaak | otherwise the testteam find bugs, and they post them on the tracker, and that's it |
| 22:35.53 | kpfleming | seanbright: mvanbaak is fairly tall |
| 22:36.00 | eliel | mvanbaak, the problem is that we don't even have a test team, regardless of the members... |
| 22:36.27 | mvanbaak | eliel: Digium has (at least I suspect because they make ABE) |
| 22:36.28 | seanbright | is 6' |
| 22:36.48 | mvanbaak | is 1m92 |
| 22:37.09 | stevie_ramjet | I think that's about the same height. |
| 22:37.43 | seanbright | is that 1 meter 92 cm? |
| 22:37.48 | stevie_ramjet | nope, mvanbaak is about 10 cm taller. |
| 22:37.55 | seanbright | damn |
| 22:37.56 | seanbright | 6'4" |
| 22:38.01 | seanbright | ~ |
| 22:38.10 | mvanbaak | ultimate situation will be: ABE == asterisk gpl version but with paid support |
| 22:38.57 | mvanbaak | and with 'asterisk gpl version' I mean latest released version |
| 22:39.22 | stevie_ramjet | Time to go to the gym. Later, fellas! |
| 22:39.26 | mvanbaak | and maybe some added extra stuff digium does not release in gpl |
| 22:40.25 | mvanbaak | btw, when was that meeting in .de again ? |
| 22:40.36 | kpfleming | May 4/5 |
| 22:41.06 | mvanbaak | thanks |
| 22:44.28 | eliel | thinks that the main problem with open source software is that too many features are added and with that too many bugs... and privately held software grows slowly.... |
| 22:44.34 | mvanbaak | 10 hours by train ... |
| 22:48.48 | *** join/#asterisk-dev telecos (n=sergio@158.167.219.87.dynamic.jazztel.es) |
| 22:51.58 | mvanbaak | eliel: that is not by definition |
| 22:53.59 | kpfleming | mvanbaak: from The Hague? |
| 22:54.43 | mvanbaak | yup |
| 22:54.46 | mvanbaak | 109 euro |
| 22:54.53 | kpfleming | ahh... not too bad, but it's a 6 hour drive :-) |
| 22:55.00 | mvanbaak | uhhuh |
| 22:55.06 | kpfleming | but fuel would cost most of 109 euro, or more |
| 22:55.09 | mvanbaak | but I dont have a car anymore |
| 22:55.14 | kpfleming | oh well never mind then |
| 22:55.55 | mvanbaak | I had one, but someone thought my car would be a great crashtest object for their car |
| 22:56.17 | mvanbaak | and since we had a 18 year old Nissan Micra it was totally trashed |
| 23:02.50 | mvanbaak | I'm off to bad |
| 23:02.59 | mvanbaak | s/bad/bed/ |
| 23:10.45 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu2.dynamic.dsl.tele.dk) |
| 23:27.57 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-212-6.west.biz.rr.com) |
| 23:30.08 | *** join/#asterisk-dev xpot (n=xpot@mx0.synergyconsultant.net) |