| 00:10.53 | *** part/#asterisk-dev wolfelectronic (n=wolfelec@91.112.227.150) |
| 00:54.16 | *** join/#asterisk-dev ZaVoid (n=zavoid@nj-76-6-39-193.dhcp.embarqhsd.net) |
| 00:56.04 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 01:31.41 | *** join/#asterisk-dev ZaVoid (n=zavoid@nj-76-6-39-193.dhcp.embarqhsd.net) |
| 02:40.13 | *** join/#asterisk-dev philipp64 (n=chatzill@mail.redfish-solutions.com) |
| 02:51.21 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 03:14.30 | *** join/#asterisk-dev ZaVoid (n=zavoid@nj-76-6-39-193.dhcp.embarqhsd.net) |
| 04:31.39 | *** join/#asterisk-dev CunningPike_ (n=arodgers@204.239.8.149) |
| 04:47.31 | *** join/#asterisk-dev jameswf (n=james@ip68-3-60-66.ph.ph.cox.net) |
| 06:33.09 | *** join/#asterisk-dev steliosk (n=Stelios@62.169.196.50) |
| 07:12.13 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:47.12 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 07:47.54 | oej | Morning |
| 07:55.36 | *** join/#asterisk-dev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 08:50.18 | *** join/#asterisk-dev fenlander (n=fenlande@82.152.81.57) |
| 08:54.39 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:54.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:31.30 | *** join/#asterisk-dev L-info (n=L-info@80.169.133.251) |
| 11:12.54 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 11:18.49 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:07.03 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 12:36.27 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:36.27 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:50.24 | *** join/#asterisk-dev ZaVoid (n=zavoid@75.147.121.177) |
| 12:58.58 | *** join/#asterisk-dev sasargen (n=chatzill@72.58.82.74) |
| 13:11.58 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:36.37 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.195.82) |
| 13:46.19 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 14:03.57 | *** join/#asterisk-dev Dovid (n=annon@tony09-118-62.inter.net.il) |
| 14:22.12 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-b114e28f8f516bec) |
| 14:22.12 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:29.27 | *** part/#asterisk-dev bweschke (n=BJ_Wesch@74.94.3.214) |
| 14:45.56 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:47.26 | sergee | are there any libpri guru awake? :) |
| 14:47.44 | sergee | there is a function called transmit_display in q931.c |
| 14:48.08 | *** join/#asterisk-dev xrg_ (n=panos@cpe-77-83-145-86-dsl.netone.gr) |
| 14:48.44 | sergee | it adds 0xb1 to the DISPLAY if pri->switchtype != PRI_SWITCH_EUROISDN_E1 |
| 14:50.09 | sergee | what is the meaning of this byte? can somebody point me to appropriate standard? |
| 14:57.34 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 14:59.16 | *** join/#asterisk-dev VoipForces (n=courchea@firewall.privalodc.com) |
| 14:59.54 | VoipForces | Hi, anyone is awaya of a NVFaxDetect port for asterisk 1.6 ? |
| 15:00.53 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 15:00.53 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 15:02.16 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 15:27.07 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.14) |
| 16:01.23 | *** join/#asterisk-dev ccesario (n=ccesario@linux.unialco.com.br) |
| 16:04.27 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:04.27 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 16:15.46 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 16:15.56 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 16:15.56 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 16:20.42 | VoipForces | Hi, anyone is awaya of a NVFaxDetect port for asterisk 1.6 ? |
| 16:24.36 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:24.36 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:27.03 | kpfleming | seanbright: sort of, yes |
| 16:27.16 | kpfleming | look at the way chan_console is built, or chan_iax2 |
| 16:27.35 | kpfleming | oh wait... that was a response to a question from monday :-) |
| 16:27.42 | seanbright | heh |
| 16:27.46 | seanbright | what question? |
| 16:27.49 | seanbright | oh |
| 16:27.51 | seanbright | multi-file |
| 16:27.51 | seanbright | right |
| 16:30.05 | kpfleming | yeah |
| 16:30.17 | kpfleming | that was last thing on my x-chat window this morning... but i logged out on monday evening |
| 16:30.37 | seanbright | yeah, the question was directed at you, but you logged off right as i sent it :) |
| 16:30.49 | seanbright | putnopvut and file answered instead, though :) |
| 16:30.55 | seanbright | meeting time. |
| 16:31.01 | putnopvut | have fun! |
| 16:32.08 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:33.30 | VoipForces | Any suggestions on outgoing fax detection when sending calls via call files on asterisk 1.6 ? |
| 16:33.41 | file | am I answering stuff without knowing it? |
| 16:34.25 | jsmith | file: always! |
| 16:40.38 | Corydon76-dig | For the purposes of silliness, today is Friday |
| 16:41.01 | jsmith | Naw... still Monday number three here. |
| 16:41.06 | Corydon76-dig | I expect you all to act accordingly. ;-) |
| 16:46.38 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:57.00 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:58.21 | VoipForces | for those interested, I was able to get nv_faxdetect to compile. But in order to have outbound fax detection to work I had to patch dsp.c |
| 17:01.29 | eliel | otherwiseguy: I have update the cli permissions review request (http://reviewboard.digium.com/r/11/) |
| 17:08.54 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 17:29.41 | VoipForces | Is there supposed to be a difference between the system dialplan command between 1.4 and 1.6 ? |
| 17:33.10 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:33.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:36.59 | Corydon76-dig | VoipForces: not that I know of |
| 17:39.24 | VoipForces | Corydon76-dig: This is what I run: |
| 17:39.28 | VoipForces | Corydon76-dig: System(/usr/bin/mysql -u root -psE4uwr9p9a fax -e \"UPDATE channels SET channels_channel_inuse=0\,channels_channel_last_hangup=now() WHERE channels_channel_number=${fax_channel}\") |
| 17:39.51 | kpfleming | wwo |
| 17:39.54 | kpfleming | or.. wow |
| 17:40.30 | Corydon76-dig | VoipForces: why don't you just use func_odbc? |
| 17:40.35 | eliel | otherwiseguy: thanks for the email |
| 17:40.52 | VoipForces | Corydon76-dig: you mean the mysql command? |
| 17:41.05 | Corydon76-dig | VoipForces: no, I mean func_odbc |
| 17:42.08 | VoipForces | Corydon76-dig: I dont see that in y "core show functions" |
| 17:42.08 | Corydon76-dig | The backport has existed since before 1.2 was even released |
| 17:42.37 | Corydon76-dig | It's not a function |
| 17:42.52 | Corydon76-dig | It's a module designed to allow you to create arbitrary functions |
| 17:43.24 | Corydon76-dig | template-based SQL |
| 17:43.36 | VoipForces | hmm reading on it on voip-info... Interesting. Thanks for the tip. |
| 17:50.07 | kpfleming | it will be far, far more efficient than your old method |
| 18:01.03 | *** join/#asterisk-dev Simon-- (n=sim@staff-nat.netnation.com) |
| 18:23.46 | VoipForces | Where do you set the mysql credentials (username/pass)? |
| 18:30.58 | Corydon76-dig | VoipForces: in res_odbc.conf |
| 18:31.36 | Corydon76-dig | func_odbc.conf points to res_odbc.conf, which points to /etc/odbc.ini, which points to /etc/odbcinst.ini |
| 18:32.14 | VoipForces | Gotta love dependencies LOL |
| 18:35.09 | Corydon76-dig | res_odbc configures connection pooling, odbc.ini configures connection names, odbcinst.ini configures database libraries |
| 18:49.31 | Corydon76-dig | Hear ye! Hear ye! Hear ye! We may have had a miscommunication on 1.6.0 merge policy. |
| 18:49.58 | Corydon76-dig | pokes kpfleming |
| 18:50.14 | kpfleming | please don't poke me |
| 18:50.23 | kpfleming | puts on his anti-poke armor |
| 18:50.48 | Corydon76-dig | Well, I'm trying to push policy communication over here |
| 18:50.56 | kpfleming | yep |
| 18:51.02 | kpfleming | i'm just being sarcastic |
| 18:51.27 | kpfleming | let's find the previous public discussions of this and post links to them here as references |
| 18:52.38 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 18:52.38 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 18:53.00 | russellb | appears |
| 18:54.53 | kpfleming | of course, in the US this is a bad day to start this discussion, as many people are already distracted |
| 18:55.10 | russellb | heh |
| 18:55.24 | seanbright | is paying attention |
| 18:55.25 | russellb | i'll put in on my list of things to post to the -dev list ... |
| 18:55.46 | kpfleming | i'd like to at least get a poll taken of the devs here to see what their understanding was |
| 18:55.58 | kpfleming | because otherwise it will bother me all weekend |
| 18:56.14 | russellb | k! |
| 18:57.07 | russellb | did you already type out the question, or would you like me to? |
| 18:57.16 | kpfleming | no, i didn't |
| 18:57.19 | kpfleming | tilghman did, sort of |
| 18:57.28 | kpfleming | so feel free |
| 18:57.39 | russellb | Ok, so, basically there is some confusion as to what the intended 1.6.X branch maintenance policy was. |
| 18:58.08 | russellb | In a private chat room, I made a comment saying that I thought we should merge _all_ bug fixes into 1.6.0 instead of just regressions introduced in that release |
| 18:58.23 | russellb | Kevin indicated that he thought that was the plan (except excluding fixes for things that are new in that release ...) |
| 18:58.38 | russellb | so basically, we're curious what other thought the policy was as far as what went into 1.6.0. |
| 18:59.26 | seanbright | regressions only |
| 18:59.53 | russellb | and by regressions you mean only things that we're broken by that release specifically? |
| 19:00.01 | seanbright | correct |
| 19:00.12 | russellb | mvanbaak: you around? |
| 19:00.25 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:00.25 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 19:02.36 | tzafrir_laptop | regressions? (vs. what base?) bug-fixes? bug-fixes that don't break anything? |
| 19:02.38 | wedhorn | when you mean "broken by that release specifically", what starting point is used? e.g we broke something in chan_skinny a couple of releases ago, is that a "regression"? |
| 19:03.12 | russellb | I guess the only goal here was to see what people _though_ the policy was |
| 19:03.23 | russellb | if you don't know, or if it sounds confusing, then that's fine too, heh |
| 19:03.24 | seanbright | the problem is... it's gray. |
| 19:03.31 | russellb | seanbright: *nods* |
| 19:03.46 | russellb | it needs to be documented somewhere :) |
| 19:03.54 | kpfleming | no, the definition of regression in this context should be pretty clear, it's not specific to asterisk |
| 19:03.58 | Corydon76-dig | At least for 1.6.0, the question was one of "Did it work at any time during the 1.4 cycle?" If it did, then it's a regression. If it had NEVER worked during 1.4 (long standing bug), then it wasn't fixable in 1.6.0. |
| 19:04.19 | russellb | yeah, what Corydon76-dig said was my understanding |
| 19:04.24 | kpfleming | a regression in 1.6.x is defined as something that worked in 1.6.x-1 but no longer does, or for 1.6.0 if it worked in 1.4 |
| 19:04.42 | seanbright | right. |
| 19:04.45 | kpfleming | yes, we said pretty much the same thing, except i extended it to beyond 1.6.0 |
| 19:04.51 | russellb | nods |
| 19:05.14 | seanbright | i only say it's gray because we don't always adhere to that 100% |
| 19:05.31 | *** join/#asterisk-dev qdk (n=qdk@94.191.225.182.bredband.3.dk) |
| 19:05.40 | russellb | but if it was broken in 1.4, 1.6.0 and 1.6.1 ... why not just fix it everywhere while the releases are still being maintained |
| 19:05.50 | kpfleming | exactly |
| 19:05.57 | kpfleming | that was exactly my plan/thought/understanding |
| 19:06.01 | russellb | right now, if a bug exists basically everywhere, it gets fixed in 1.4, trunk, and the latest 1.6.X that is stil in beta/rc |
| 19:06.09 | kpfleming | and many fixes have been handled exactly that way |
| 19:06.13 | VoipForces | Comming back to the syste command, looks like I do not have to escape the comma anymore in 1.6. What about the single quote? |
| 19:06.16 | tzafrir_laptop | So something like http://downloads.digium.com/pub/asa/AST-2008-011.html does not count as a regression and needs no fixing |
| 19:06.28 | russellb | kpfleming: I think most haven't been ... |
| 19:06.29 | tzafrir_laptop | is badly lagging now |
| 19:07.09 | kpfleming | can someboyd find the asterisk-dev post where we first communicated this policy? |
| 19:07.50 | russellb | there was the original 1.6 release management discussion over a year ago, and then it has been communicated by word of mouth since |
| 19:08.03 | russellb | but i'll find the old discussion, one minute |
| 19:08.47 | russellb | http://lists.digium.com/pipermail/asterisk-dev/2007-October/030083.html |
| 19:10.10 | eliel | "by word of mouth" = VoA (Voice over Air) |
| 19:10.44 | Corydon76-dig | eliel: and IRC |
| 19:10.45 | kpfleming | ok, so yes, that was fairly clear, but not what i wanted it to be, so i misread it and never commented |
| 19:10.46 | kpfleming | my bad |
| 19:11.07 | putnopvut | I haven't weighed in yet, but my understanding was that bug fixes in 1.4 were not to go into 1.6.0 since by definition they could not be regressions. But I disagree with the policy. |
| 19:11.10 | eliel | Corydon76-dig: yeaph, he |
| 19:11.15 | kpfleming | that post clearly states what nearly everyone agrees is what is currently happening |
| 19:11.29 | seanbright | and what was that again? |
| 19:11.30 | seanbright | heh |
| 19:11.39 | Corydon76-dig | kpfleming: well, I've heard several complaints about the policy, so while it may be too late to fix for 1.6.0, we could propose a policy change for 1.6.1 and forward. |
| 19:11.49 | kpfleming | and, everyone disagrees with that policy, and i thought the policy was already what people wanted it to be :-) |
| 19:11.56 | kpfleming | no, we need to fix 1.6.0 |
| 19:12.10 | russellb | tough situation |
| 19:12.11 | kpfleming | if 1.4.23 has bug fixes that 1.6.0.2 does not, we are broken |
| 19:12.17 | russellb | but at least we agree on what should be the policy |
| 19:12.21 | russellb | kpfleming: we are broken :( |
| 19:12.24 | lmadsen | kpfleming: +1 from me |
| 19:12.31 | lmadsen | russellb: -1 for you |
| 19:12.39 | russellb | lmadsen: wtf? |
| 19:12.44 | seanbright | girl fight! |
| 19:12.45 | russellb | and I don't know how much work it will take to fix it |
| 19:12.46 | lmadsen | russellb: I'm joking |
| 19:12.53 | russellb | but probably a pretty good amount |
| 19:12.56 | kpfleming | if users upgrade from current 1.4 to current 1.6 and have bugs reintroduced, then i'd think that is generally unacceptable |
| 19:13.02 | Corydon76-dig | kpfleming: since you brought up the discussion, would you like to post the summary on -dev? |
| 19:13.02 | russellb | agrees |
| 19:13.09 | kpfleming | yes, i can do that |
| 19:13.17 | Corydon76-dig | with a [policy] tag |
| 19:13.18 | russellb | i don't mind doing it |
| 19:13.21 | russellb | i kinda brought it up, heh |
| 19:13.37 | russellb | by proposing a change to the policy to make it what kpfleming already wanted it to be, heh |
| 19:13.37 | Corydon76-dig | russellb: I figured you were busy |
| 19:13.37 | kpfleming | that's fine too |
| 19:13.47 | Qwell | kpfleming: minor flaw with your statement |
| 19:13.51 | lmadsen | another alternative to getting 1.6.0 back up to date with all bug fixes is to abandon it and start with 1.6.1 ? |
| 19:13.54 | kpfleming | i will then vehemently disagree with your proposed change |
| 19:14.00 | russellb | kpfleming: good plan |
| 19:14.11 | Corydon76-dig | lmadsen: that's basically what I proposed |
| 19:14.17 | Qwell | It's possible for 1.4 to have a release that contains a fix, and 1.6.x branch would contain that fix, but maybe a release wasn't made yet |
| 19:14.19 | russellb | kpfleming: however, the last point to debate is whether we put in fixes for new features |
| 19:14.20 | lmadsen | sorry... s/1.6.0/1.6 |
| 19:14.21 | russellb | I think we should :) |
| 19:14.39 | lmadsen | Corydon76-dig: makes sense to me |
| 19:14.46 | kpfleming | Qwell: but older 1.6.x branches should get the same fix as 1.4 and have releases made |
| 19:14.47 | russellb | for a feature that is new in 1.6.X, do we put in bug fixes for it for 1.6.X.Y |
| 19:14.52 | lmadsen | a bug fix or two are bound to be missed regardless... |
| 19:15.03 | putnopvut | russellb: I think so |
| 19:15.18 | putnopvut | But I also know that that does not jibe with the current policy. |
| 19:15.19 | Qwell | so basically, if we do a 1.4 bug fix release, we should be doing a 1.6.x release (if it contains 1 or more of the bugs)? |
| 19:15.21 | russellb | lmadsen: if they get missed, then we have problems with our commit practices ... |
| 19:15.22 | kpfleming | and making a 1.4 release should trigger releases of all bugfix-only 1.6.x branches |
| 19:15.26 | kpfleming | Qwell: yes |
| 19:15.29 | Qwell | perfect |
| 19:15.38 | Qwell | I think that's an important clarification to make |
| 19:15.53 | kpfleming | not an -rc, but an actual release |
| 19:16.01 | Qwell | right |
| 19:16.09 | kpfleming | and we shouldn't need -rcs for those 1.6 branches, but we could make them if we wanted to |
| 19:16.15 | VoipForces | FYI, the syste command in 1.6 does not require escaping of comma and single quote like it used to be in 1.4 |
| 19:16.17 | putnopvut | kpfleming: does "bugfix-only 1.6.x branches" mean released 1.6.x branches? |
| 19:16.22 | kpfleming | yes |
| 19:16.28 | putnopvut | okay, just double checking. |
| 19:16.32 | russellb | kpfleming: did you see my question about feature fixes? |
| 19:16.37 | kpfleming | all 1.6.x branches except the current development branch |
| 19:16.45 | kpfleming | russellb: yes, but that's a bigger change i'm not ready to make |
| 19:16.45 | lmadsen | VoipForces: yes, that was documented in UPGRADE.txt or CHANGES I'm pretty sure |
| 19:16.52 | russellb | kpfleming: ok. |
| 19:17.12 | russellb | here's another question ... |
| 19:17.15 | VoipForces | I did a search in UPGRADE and did not find anuthing related |
| 19:17.33 | russellb | what about a feature that is new in 1.6.0, but broken. Is it ok to merge fixes into 1.6.1 after it is released and in bug-fix mode? |
| 19:17.44 | russellb | it's not a new feature in that release :) |
| 19:17.50 | Qwell | russellb: >.< |
| 19:17.58 | russellb | well, it's a valid question |
| 19:18.05 | kpfleming | thinks |
| 19:18.08 | Qwell | it's also not a new bug |
| 19:18.08 | russellb | we have to find the proper definition, or the policy is still vague ... |
| 19:18.17 | Corydon76-dig | VoipForces: Core, third item |
| 19:18.48 | russellb | you can put in fixes for features that worked at some point in a previous release? |
| 19:19.07 | russellb | if it has never worked, fixes only go into the next 1.6.X? |
| 19:19.14 | Qwell | that's what I'd think |
| 19:19.15 | russellb | very ... wishywashy |
| 19:19.22 | kpfleming | so if we did that, then i see no reason not to put the fixes into the release where the feature was added |
| 19:19.30 | russellb | agrees |
| 19:19.38 | lmadsen | a bug fix is a bug fix... ? |
| 19:19.38 | kpfleming | either it's 'next release only', or all releases that have the feature |
| 19:19.38 | russellb | and how do you define if a feature every "worked" |
| 19:19.56 | lmadsen | regardless of whether it was a new feature, or not? |
| 19:19.56 | Corydon76-dig | russellb: "behaves as documented" |
| 19:20.04 | putnopvut | I would think that it worked to some degree if it was added to the mainline source. |
| 19:20.11 | russellb | putnopvut: exactly |
| 19:20.13 | kpfleming | i would hope so |
| 19:20.13 | lmadsen | would make it slightly easier to determine where it should be fixed |
| 19:20.16 | Qwell | putnopvut: good point.. |
| 19:20.31 | russellb | like ... SIP/TCP for example |
| 19:20.48 | putnopvut | Right, there are aspects of that that work great, but others that are horribly broken. |
| 19:20.50 | VoipForces | Thanks Corydon76-dig... I had done a search on system... |
| 19:20.52 | russellb | it's not _completely_ broken |
| 19:20.56 | Corydon76-dig | The point of the policy was to limit the amount of excess work done by the development team |
| 19:21.14 | kpfleming | exactly |
| 19:21.17 | russellb | limit work, sure, but we don't want to render releases useless by neglecting to give them fixes |
| 19:21.25 | VoipForces | BTW, currently sending faxes via a PRI on 21 channels using asterisk 1.6. |
| 19:21.31 | VoipForces | load average: 0.04, 0.02, 0.00 |
| 19:21.37 | kpfleming | VoipForces: when upgrading, you need to read the entire file, not search for specific things that might be too narrow in scope |
| 19:21.46 | lmadsen | VoipForces: you should probably direct your questions to #asterisk |
| 19:21.47 | kpfleming | you need to read the file BEFORE upgrading, not after when you find a problem |
| 19:21.56 | Corydon76-dig | russellb: So our initial implementation of the policy was far too restrictive, and we loosen it slightly |
| 19:22.10 | russellb | I'm ok with that in general |
| 19:22.20 | russellb | as long as we can come up with a definition that is clear |
| 19:22.29 | russellb | i haven't found it yet for this limit on features situation |
| 19:22.34 | wedhorn | how about tagging new features in trunk as "experimental" and the branches aren't updated until the experimental tag is removed? |
| 19:22.38 | kpfleming | i'm fine with a feature being added in 1.6.x, not being generally 'bug free' until 1.6.x+4, if that's what it takes for the community to find the issues |
| 19:22.43 | Corydon76-dig | I think if we consider that we're still not overworked in terms of that, we can consider fixing new features |
| 19:22.56 | lmadsen | this may also put manxpower at ease, as he has been harping that he doesn't want to have to go to 1.6.x+1 to get bug fixes when new features are being released in addition |
| 19:23.12 | Corydon76-dig | but we need to have time for that change to take effect and sink in before we consider taking on additional work |
| 19:23.15 | russellb | lmadsen: yes, it should |
| 19:23.15 | kpfleming | except for bugs that were in 1.6.x's new features |
| 19:23.20 | VoipForces | lmadsen: Usually do. |
| 19:24.04 | Corydon76-dig | kpfleming: I'm saying, we don't fix them at this juncture, but we can consider that at some point in the future, if demands warrant an additional change |
| 19:24.07 | russellb | kpfleming: right, but I still don't know what the policy would be for that same feature in 1.6.[X + 1] |
| 19:24.18 | kpfleming | hang on |
| 19:24.21 | kpfleming | let me finish typing |
| 19:24.23 | russellb | ha |
| 19:25.23 | kpfleming | SIP/TCP is a good example. it's a major new feature in 1.6.0, and the changes were quite invasive. the changes to FIX it are also going to be invasive. does anyone want to risk destabilizing 1.6.0, 1.6.1, 1.6.2, etc. just because we *MIGHT* have correct fixes for SIP/TCP, or do we just let them shake out in trunk until we are really sure they are fixed and then they go into 1.6.3 |
| 19:25.55 | russellb | thinks for a moment |
| 19:26.01 | Corydon76-dig | So the question really is one of invasiveness of a fix |
| 19:26.09 | kpfleming | no |
| 19:26.16 | kpfleming | the policy cannot be based on that |
| 19:26.25 | russellb | It's really hard to make a generic policy out of this |
| 19:26.30 | putnopvut | kpfleming: it already is though |
| 19:26.31 | kpfleming | because that is subjective, and people will make the wrong decisions, an our community will be burned by it |
| 19:26.42 | putnopvut | kpfleming: section 3.2.4 of the e-mail linked earlier. |
| 19:27.29 | russellb | Honestly, yes, I think all fixes for SIP/TCP should go into every supported 1.6.X |
| 19:27.35 | russellb | the fixes shouldn't go in until we are confident with them |
| 19:27.48 | russellb | and then we should properly take advantage of the release candidate process to ensure that it gets proper testing |
| 19:27.54 | kpfleming | no, 3.2.4 refers to stuff that is known to be invasive and is a policy for holding it out from trunk |
| 19:27.55 | lmadsen | how do you get confidence outside of production testing? (just a question) |
| 19:28.12 | lmadsen | question answered |
| 19:28.15 | putnopvut | lmadsen: it's darn hard to. |
| 19:28.15 | russellb | strict code review, and good quality testing. |
| 19:28.20 | russellb | it's hard for sure |
| 19:28.24 | russellb | and if we cause a regression, we'll fix it |
| 19:28.32 | lmadsen | reviewboard seems to have helped I think in terms of better code though luckily |
| 19:28.33 | russellb | it happens, but we'll surely work as hard as we can to prevent it |
| 19:29.30 | kpfleming | ok, here's the larger issue: i don't think we have the tools in place to support that mode of operation (all fixes go into all candidate branches) |
| 19:29.30 | Corydon76-dig | russellb: I think Kevin has made a good argument on this. |
| 19:29.30 | russellb | drawing the line between what fixes go in and don't with a clear generic policy is really difficult |
| 19:29.30 | russellb | it'd have to be case by case ... |
| 19:29.30 | lmadsen | I think if you don't fix the SIP/TCP bug, then you end up not fixing bugs in features at all, which again causes people to move to 1.6.x+1 when they don't want to |
| 19:29.30 | russellb | kpfleming: yeah, we do. the svnmerge setup works fine for it |
| 19:29.31 | russellb | you just mergetrunk6 into each 1.6.X branch |
| 19:29.46 | Corydon76-dig | russellb: right, which is why I think Kevin's suggestion, while it may be restrictive, is also fair and easy to comprehend |
| 19:29.49 | kpfleming | note that we are not saying those bugs cannot be fixed in 1.6.0.y release; only that we aren't comfortable committing the developer time to doing it |
| 19:29.51 | lmadsen | the question is whether that is something we are aiming to do (not require .X+1 upgrades to get a bug fix) |
| 19:30.04 | russellb | I _don't understand the suggestion_ I have yet to see a generic policy statement |
| 19:30.40 | seanbright | i gotta be honest... at this rate... the old way doesn't seem so bad |
| 19:30.53 | russellb | it does seem bad, 1.6.0 is already becoming a useless release to run |
| 19:30.57 | Corydon76-dig | russellb: Fixes for features new to the 1.6 series shall be committed only in trunk and in unreleased 1.6.x branches |
| 19:31.02 | russellb | as 1.4 and 1.6.1 already have a number of fixes that 1.6.0 does not have |
| 19:31.12 | seanbright | russellb: i meant the old old way |
| 19:31.23 | russellb | Corydon76-dig: even a feature introduced in 1.6.0 when we're up to 1.6.15 ? |
| 19:31.26 | russellb | seems sillt |
| 19:31.26 | seanbright | 1.2, 1.4, 1.6, 1.8, etc. |
| 19:31.27 | russellb | silly* |
| 19:31.33 | russellb | seanbright: oh, heh |
| 19:31.48 | Corydon76-dig | russellb: silly, perhaps, but it's a clearly defined policy without subjective judgements |
| 19:32.02 | russellb | I can agree that it is a clear statement. |
| 19:32.03 | kpfleming | and it's a step forward from where we are right now |
| 19:32.16 | seanbright | it doesn't really serve the users, however. |
| 19:32.17 | russellb | I very much do not agree that it is better than just putting the fixes in every supported release |
| 19:32.25 | kpfleming | because right now 1.6.0 is a regression from 1.4.23 |
| 19:32.45 | *** part/#asterisk-dev VoipForces (n=courchea@firewall.privalodc.com) |
| 19:32.47 | lmadsen | the only thing I don't like about it is it forces someone to move from a known quantity to an unknown quantity with multiple, new features |
| 19:32.50 | kpfleming | i don't believe anyone is claiming it is better for users |
| 19:33.00 | seanbright | heh |
| 19:33.03 | lmadsen | is just being devils advocate btw |
| 19:33.07 | kpfleming | lmadsen: then 1.6.0 == 1.6, 1.6.1 == 1.8, 1.6.2 == 1.10, etc. |
| 19:33.09 | seanbright | we should put that statement on the homepage |
| 19:33.12 | seanbright | :P |
| 19:33.43 | kpfleming | what i meant was that yes, merging bugfixes into all possible branches would certainly be *EVEN* better than this proposal, but i am concerned about the time impact |
| 19:33.47 | lmadsen | kpfleming: fair enough, so I suppose the code base should really be relatively the same, but just with an additional feature? |
| 19:33.54 | kpfleming | what is proposed is most definitely better than what we have today |
| 19:34.20 | lmadsen | what if you limited the bug fix to .X-3 releases or something? does that help at all? |
| 19:34.23 | kpfleming | lmadsen: that depends. SIP/TCP ripped apart chan_sip, and kill-the-user and astobj2 (in 1.6.1) did the same |
| 19:34.26 | lmadsen | (in terms of features) |
| 19:34.31 | kpfleming | that was already the plan |
| 19:34.43 | Corydon76-dig | I'm going to delay the release of 1.6.0.2 until at least Monday, and I'll get started on reviewing fixes in 1.6.1 that were not committed to 1.6.0. |
| 19:34.52 | russellb | kpfleming: what if we made putting all fixes in everywhere the standard, except for special case exceptions, where it just too darn invasive. |
| 19:34.55 | russellb | let's make the norm fixing stuff. |
| 19:35.09 | kpfleming | who decides what is too invasive? |
| 19:35.11 | russellb | and if we just can't because for some reason it is unreasonable (chan_sip has been half rewritten or whatever) then fine |
| 19:35.12 | russellb | we do :) |
| 19:35.19 | putnopvut | kpfleming: the developer introducing the fix, most likely |
| 19:35.35 | Corydon76-dig | russellb: because it's a subjective decision that is fraught with peril as some people think that we're splitting hairs |
| 19:35.37 | russellb | the developer at their own discretion if it's obvious, or defer to kevin or I if we have to |
| 19:35.57 | russellb | ok then fine, put all fixes in every release we support. |
| 19:36.03 | russellb | that's my suggestion :) |
| 19:36.03 | Corydon76-dig | I like having a clear policy better |
| 19:36.04 | kpfleming | so here's the rub: what if the fix in 1.6.1 is easy because the code has been rewritten again, but in 1.6.0 it's going to take five times as long |
| 19:36.04 | lmadsen | the other example I think is the issue with chan_agent that mark found yesterday |
| 19:36.10 | seanbright | agrees with russellb |
| 19:36.19 | putnopvut | lmadsen: which one? |
| 19:36.27 | lmadsen | putnopvut: the many warnings or whatever that you were seeing |
| 19:36.34 | putnopvut | lmadsen: ah, that, yes. |
| 19:36.49 | lmadsen | although I suppose that wasn't a new feature, so maybe my point is moot |
| 19:36.53 | wedhorn | why don't you predefine what can be included. kpfleming gave the example of SIP TCP. Mark it as experimental (no fixes). At some stage, remove the mark and then fixes are committed. |
| 19:37.05 | wedhorn | It removes the subjectiveness around bugfixes |
| 19:37.18 | russellb | kpfleming: we have 3 options. 1) We set our policy such that we have to suck it up. 2) We give ourselves the option to make exceptions in rare cases. I really don't think this would be often! or 3) we limit what fixes go into what releases (which is my least favorite by far) |
| 19:37.18 | wedhorn | (and moves them to the development phase) |
| 19:37.44 | russellb | right, the mark of "experimental" could be how we make the exceptions I'm talking about |
| 19:37.55 | russellb | of course, marking something experimental is subjective, too ... |
| 19:37.56 | kpfleming | wedhorn: because during subequent releases it will get fixes, otherwise the interim fixes won't get tested |
| 19:38.04 | russellb | the whole exception thing is subjective period |
| 19:38.24 | lmadsen | has subjectiveness up to now been a positive or a negative? |
| 19:38.36 | russellb | depends who you ask |
| 19:38.39 | kpfleming | yeah |
| 19:38.51 | russellb | I'm ok with being able to say "in this case, since it'll take 5 times as long, we're making an exception" |
| 19:39.00 | seanbright | another interesting discussion would be about QA and policies that we should put in place to try and limit the bugs that actually get out in the wild in the first place |
| 19:39.02 | russellb | and I would even want to limit the cases that is an option to require special approval |
| 19:39.11 | seanbright | but that's for another time. |
| 19:39.15 | russellb | seanbright: *nods* |
| 19:39.31 | kpfleming | when someone wants to pay for the cost of QA, it'll happen |
| 19:39.36 | seanbright | heh |
| 19:39.38 | russellb | basically, heh |
| 19:39.41 | kpfleming | when it's all volunteer and overworked digium staff, it won't |
| 19:40.00 | wedhorn | kpfleming: I'm lost, why wouldn't interim fixes get tested? They'd be in trunk and subsequent releases. |
| 19:40.07 | seanbright | you guys have had like 26 profitable quarters in a row... hire someone :) |
| 19:40.15 | kpfleming | i misunderstood your proposal, wedhorn |
| 19:40.26 | kpfleming | we have. we have hired over a dozen developers. |
| 19:40.33 | kpfleming | there is more work than they can do in the best of times |
| 19:40.57 | file | unfortunately you can't have it all... with the number of us |
| 19:41.20 | kpfleming | honestly, i doubt it matters how many people we have unless it got to 40-50 |
| 19:41.31 | kpfleming | the work will expand to fill the time available |
| 19:41.35 | kpfleming | the more we do, the more people expet |
| 19:41.47 | russellb | yes, that has been the trend ... |
| 19:41.54 | *** join/#asterisk-dev ccesario (n=ccesario@189.20.219.10) |
| 19:42.33 | kpfleming | plus 'QA' means writing test plans, and test plans can't be written without specifications for the changes that were made |
| 19:42.42 | kpfleming | 'go test SIP/TCP' is not a test plan |
| 19:42.46 | kpfleming | we did that, it passed |
| 19:42.46 | *** join/#asterisk-dev otherwiseguy (n=otherwis@72.128.38.41) |
| 19:43.06 | seanbright | i'll butt out. |
| 19:43.20 | kpfleming | why/ |
| 19:43.40 | kpfleming | in fact, SIP/TCP still works for a lot of people in simple applications |
| 19:43.47 | russellb | indeed. |
| 19:43.52 | seanbright | well, i'm not specifically talking about SIP/TCP |
| 19:44.03 | kpfleming | speak up then :-) |
| 19:44.08 | seanbright | talking about stuff like the MiniVM conversation from yesterday |
| 19:44.10 | russellb | so is it is considered a working feature or not for the purposes of policy :) |
| 19:44.23 | kpfleming | ah, sorry i missed that one |
| 19:44.33 | seanbright | which basically uncovered that an application had been broken in 1.4 for x number of releases |
| 19:44.41 | seanbright | thats smoke-test stuff |
| 19:44.50 | seanbright | and with all due respect |
| 19:44.57 | seanbright | asterisk is digium's business |
| 19:45.00 | seanbright | unless i'm missing something |
| 19:45.07 | kpfleming | in a way |
| 19:45.34 | kpfleming | but like everyone else we focus on the major pieces of functionality that people use, and that we get bug reports for |
| 19:45.43 | seanbright | if i was in a position that i was making my entire living off of asterisk and could contribute more time and hardware to building test plans, etc. i would. |
| 19:45.55 | kpfleming | if we wanted to verify that every code path in asterisk works as it should, we'd spend the next 10 years doing it |
| 19:46.09 | kpfleming | seanbright: we know, we'd like you to be able to do that :-) |
| 19:46.14 | seanbright | heh |
| 19:46.23 | seanbright | but i don't have the time or the resources for that |
| 19:46.32 | russellb | you and the rest of the volunteers |
| 19:46.35 | russellb | hence the situation we're in |
| 19:46.36 | russellb | :) |
| 19:46.36 | seanbright | precisely |
| 19:46.48 | kpfleming | honestly, i don't think we are all that different from other large open source projects. bugs (really old bugs) get found and fixed all the time |
| 19:46.53 | russellb | and really, we _do_ test a lot of stuff in house |
| 19:46.59 | russellb | but we just can't get everything |
| 19:47.27 | kpfleming | our testing focuses on what our commercial customers want to use for obvious reasons |
| 19:47.32 | seanbright | sure |
| 19:47.41 | russellb | and they are overworked like the rest of us : |
| 19:47.42 | russellb | :) |
| 19:47.43 | seanbright | i'm just saying we don't talk about it all that much |
| 19:47.48 | seanbright | developer testing, then release |
| 19:47.53 | seanbright | that's pretty much what i see. |
| 19:48.02 | seanbright | well |
| 19:48.03 | russellb | and that's pretty much what you get for the bleeding edge open source releases |
| 19:48.17 | seanbright | developer testing, commit, hopefully someone uses it in production during the RC phase, release |
| 19:48.20 | russellb | ideally the release candidate cycle expands that pre-release test base |
| 19:48.25 | russellb | right. |
| 19:48.59 | russellb | and RCs have helped a good bit in the past |
| 19:49.00 | seanbright | well, anyway, i've completely forgotten what point i was trying to make, if any |
| 19:49.10 | russellb | but there have been other cases where clearly nobody tried some huge part of asterisk during that time ... |
| 19:49.32 | wedhorn | eg chan_skinny |
| 19:49.50 | russellb | seanbright: I think you were trying to throw a match into some fire and run, but then we didn't let you run |
| 19:49.56 | russellb | s/fire/gasoline/ |
| 19:49.57 | russellb | something like that |
| 19:50.03 | seanbright | not at all |
| 19:50.31 | seanbright | "another interesting discussion would be about QA and policies that we should put in place to try and limit the bugs that actually get out in the wild in the first place" |
| 19:50.47 | russellb | yeah ... i was trolling. |
| 19:51.01 | seanbright | the OSS side of asterisk does /nothing/ other than developer testing as far as i can tell |
| 19:51.03 | russellb | perfectly good statement to make, and is a good thing for any project to talk about |
| 19:51.09 | otherwiseguy | feeds russellb the troll |
| 19:51.14 | russellb | seanbright: that's pretty accurate |
| 19:51.20 | russellb | and make RCs : |
| 19:51.22 | russellb | :) |
| 19:51.35 | lmadsen | so until we got distracted... did we determine what the new policy is? :) |
| 19:51.42 | russellb | not IMO |
| 19:51.42 | seanbright | kevin is writing it |
| 19:51.44 | seanbright | heh |
| 19:52.08 | russellb | I'd be happy to write it if I thought we agreed ... otherwise I'll write up (as best I can) the policy, and the parts that are still under debate |
| 19:52.13 | russellb | for more organized discussion on the -dev list |
| 19:52.25 | lmadsen | russellb: I think that makes sense... perhaps we need more input from the community |
| 19:52.29 | seanbright | i didn't mean to hijack the discussion, for the record. |
| 19:52.30 | putnopvut | Yes, I can't keep up with IRC discussions. |
| 19:52.38 | russellb | However, as long as nobody minds, I'd like to postpone that discussion on the list until Monday, because I don't want to have to constantly check and keep up with it over the holiday weekend |
| 19:52.40 | kpfleming | yes, we should post this on the list first for discussion |
| 19:52.47 | kpfleming | i agree |
| 19:52.49 | russellb | yay |
| 19:52.52 | lmadsen | motion passed |
| 19:52.59 | russellb | then I will make time to summarize the situation on -dev on Monday |
| 19:53.04 | russellb | has it on the list! |
| 19:53.13 | kpfleming | cool |
| 19:53.32 | russellb | that was nice ... I haven't had a good long IRC debate in a while. |
| 19:53.34 | russellb | heh |
| 19:53.41 | seanbright | needs a smoke |
| 19:53.46 | russellb | needs a beer |
| 19:53.47 | russellb | wait .. |
| 19:53.48 | file | russellb: you earned some IRC time! |
| 19:53.52 | russellb | file: <3 |
| 19:54.37 | russellb | settles for kool-aid |
| 19:54.37 | russellb | Crystal Light, actually. |
| 19:54.37 | otherwiseguy | works from home so looks for beer |
| 19:54.41 | lmadsen | russellb: mmmm |
| 19:54.49 | seanbright | works from work so looks for work |
| 19:54.53 | lmadsen | poured a glass of milk |
| 19:55.07 | file | stabs his work and declares party time |
| 19:55.22 | kpfleming | needs to get a very late lunch and go home so he can continue working on skype |
| 19:55.24 | seanbright | the last thing i will say is this... |
| 19:55.36 | seanbright | make sure to thaw the turkey before deep frying it |
| 19:56.10 | putnopvut | lol |
| 20:00.25 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 20:01.08 | lmadsen | pls! |
| 20:06.28 | *** join/#asterisk-dev ajohnson (n=ajohnson@63.147.46.186) |
| 20:07.24 | Corydon76-dig | seanbright: reminds me, I need to brine my turkey tonight |
| 20:10.48 | seanbright | yeah... i have to "brine" my "turkey" tonight too |
| 20:11.50 | *** join/#asterisk-dev otherwiseguy (n=otherwis@cpe-72-128-38-41.kc.res.rr.com) |
| 20:13.33 | putnopvut | Something screwy is going on in 1.4 right now. |
| 20:13.37 | putnopvut | svn update is failing |
| 20:13.54 | putnopvut | "svn: Failed to add file 'channels/busy.h': object of the same name already exists" |
| 20:14.39 | putnopvut | My guess is that this is due to revision 159476 |
| 20:15.04 | russellb | commit asterisk 159476 |
| 20:15.09 | MuffinMan | [159476] Committed by kpfleming on 2008-11-26T18:36:24.612340Z: simplify (and slightly bug-fix) the recent developer-oriented COMPILE_DOUBLE mode |
| 20:15.09 | MuffinMan | .. |
| 20:15.09 | MuffinMan | ..add channels/busy.h and channels/ringtone.h to the repository instead of generating them repeatedtly; most users do not change the settings to build them, but the Makefile rules are still there if they wish to do so |
| 20:15.09 | MuffinMan | .. |
| 20:15.12 | MuffinMan | ..ensure that 'make clean' removes dependency files for .i files that are created in COMPILE_DOUBLE mode |
| 20:15.15 | MuffinMan | .. |
| 20:15.17 | MuffinMan | .. |
| 20:15.19 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=159476 |
| 20:15.31 | russellb | ah |
| 20:15.33 | putnopvut | Hmm, I guess I can just remove the file and re-update. |
| 20:15.35 | russellb | just rm channels/busy.h |
| 20:15.38 | russellb | and rm channels/ringtone.h |
| 20:15.38 | russellb | yes. |
| 20:15.40 | putnopvut | Then it shouldn't occur again. |
| 20:15.43 | russellb | right |
| 20:18.12 | kpfleming | sorry about that |
| 20:18.17 | kpfleming | i didn't realize that svn would do that |
| 20:18.18 | putnopvut | It's cool. |
| 20:18.32 | russellb | clearly a reason to switch SCMs, lol |
| 20:18.39 | kpfleming | would it better to make a followup commit to change their names? i think so, otherwise tons of people will gets this problem |
| 20:18.50 | kpfleming | no, it's not the SCM's fault |
| 20:18.58 | kpfleming | an unversioned file is sitting there already |
| 20:18.59 | russellb | i know, i'm just ... trolling i guess |
| 20:19.04 | putnopvut | kpfleming: yeah, that seems like a good idea to me. |
| 20:19.09 | russellb | but yeah, that would be could |
| 20:19.13 | kpfleming | will do |
| 20:19.17 | russellb | good, too |
| 20:21.12 | kpfleming | done, somone else update their working copy please to test it |
| 20:22.14 | otherwiseguy | i updated fine. |
| 20:22.18 | kpfleming | yay |
| 20:22.31 | kpfleming | so now you have two bogus files that 'svn status' will show question marks for |
| 20:22.44 | otherwiseguy | indeed |
| 20:22.54 | otherwiseguy | along with my 15 core files. :-) |
| 20:23.00 | russellb | ha, nice |
| 20:26.04 | otherwiseguy | alias astgdb='sudo gdb asterisk `ls -t core*|head -1`' make it much easier to gdb the right one... |
| 20:27.25 | otherwiseguy | doesn't usually fix the crash on the first try |
| 20:29.00 | kpfleming | ok, so i accidentally just ran postreview with '-r 6', but it did not complain |
| 20:29.07 | kpfleming | that review is closed, and isn't even mine |
| 20:29.27 | kpfleming | so the review request was not posted, even though the script says it was |
| 20:29.45 | russellb | huh. |
| 20:30.01 | russellb | I guess we'd have to bug reportify it |
| 20:30.07 | russellb | at least it didn't post the diff on there, heh |
| 20:30.23 | kpfleming | yeah, i checked |
| 20:30.34 | kpfleming | i bet it is there, if we reopened that request |
| 20:32.02 | russellb | i reopened it |
| 20:32.05 | russellb | it's not there |
| 20:34.00 | kpfleming | ok, optional_api review has been updated |
| 20:54.15 | russellb | stringifies kpfleming |
| 20:54.21 | kpfleming | ouch |
| 20:56.26 | *** join/#asterisk-dev telecos (n=sergio@67.166.219.87.dynamic.jazztel.es) |
| 20:56.54 | russellb | kpfleming: so I guess if an optional API call returned something other than int, we would just define another common return value for stubs ... |
| 20:56.59 | russellb | ? |
| 20:57.08 | russellb | s/.../?/ heh |
| 20:57.17 | kpfleming | yes |
| 20:57.20 | russellb | k! |
| 20:57.23 | kpfleming | or it would be special to that API |
| 20:57.51 | kpfleming | and for some, being not present is not a problem (like ast_moh_start) |
| 20:58.11 | kpfleming | so they might return 'success', or 'no messages found', or 'no ADSI client' |
| 20:58.16 | russellb | ah, true |
| 20:58.20 | russellb | marks ship it |
| 20:59.02 | russellb | failed to find a bug in your code |
| 20:59.31 | kpfleming | there was a major one in the last version |
| 20:59.41 | kpfleming | but it was in the _ATTR version of the macro, which wasn't being used then |
| 21:00.10 | russellb | and wasn't in the diff ... *kicks svn* |
| 21:00.15 | kpfleming | yeah |
| 21:00.27 | russellb | i guess i could ask the users IRC channel |
| 21:00.37 | russellb | but it doesn't look like there is a way |
| 21:04.13 | kpfleming | svn diff caveats posted to -dev |
| 21:10.59 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:10.59 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 21:39.04 | *** join/#asterisk-dev DarkRift (n=dark@65.92.171.125) |
| 21:47.47 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/daviey) |
| 22:29.53 | *** join/#asterisk-dev telecos (n=sergio@67.166.219.87.dynamic.jazztel.es) |
| 22:36.26 | *** join/#asterisk-dev voxter (n=voxter@76.77.95.2) |
| 22:37.17 | voxter | Before I upgrade one of my production gateways to 1.4, I've got an issue with 1.2 here where "randomly" (ie I cant identify it yet) the cpu usage will jump from 5-20% all the way up to 80%, sit there for a minute or two, then come back down (top shows it all contained in the asterisk process) |
| 22:37.32 | voxter | Is there a way I can debug what module/component is responsible? |
| 22:37.51 | voxter | I was doing an strace on the process, but that seemed to piss asterisk off after a few seconds and crash it. |
| 22:38.07 | seanbright | strace on a production asterisk is not a good plan |
| 22:38.08 | voxter | nothing stands out in the logs, or in the number of channels in use during the high/low periods |
| 22:38.14 | voxter | Yeah, I found out the hard way :) |
| 22:38.34 | seanbright | i'm not really sure what you would do in 1.2 |
| 22:38.49 | russellb | upgrade to 1.4 and then you can call it a bug, and open a report :) |
| 22:38.53 | seanbright | heh |
| 22:39.08 | voxter | Yeah. The box needs to be upgraded to 1.4 either way, but I'd still like to figure this out. Aside from this problem (which i think may be the cause of some periodic dropped calls) its running like a champ. |
| 22:39.14 | russellb | there is no way to guess what it is ... |
| 22:39.23 | seanbright | voxter: there is a GOOD chance that your problem is resolved in 1.4 |
| 22:39.30 | voxter | cant attach to it with gdb? |
| 22:39.34 | seanbright | voxter: and only a slight chance that something else is broken |
| 22:39.35 | russellb | yeah, you can gdb it |
| 22:39.36 | seanbright | :) |
| 22:39.48 | russellb | of course, it's locked up while you have gdb attached |
| 22:39.55 | voxter | well, thats out. :) |
| 22:40.00 | russellb | you can use gcore to get a core dump |
| 22:40.06 | russellb | which only locks it up for a moment |
| 22:40.11 | russellb | i think we even have a script for that |
| 22:40.14 | russellb | ast_grab_core i think |
| 22:40.22 | russellb | i haven't used that in forever ... |
| 22:40.59 | seanbright | contribu/scripts/ast_grab_core |
| 22:41.08 | seanbright | minus that 'u' in there |
| 22:41.53 | voxter | I am not exactly up on my debugger/core dump reading skills. Is it possible if i grab a core dump while the cpu usage is high, one of you could spot it? |
| 22:42.40 | seanbright | hmmm, that script doesn't use gcore |
| 22:42.45 | russellb | orly |
| 22:42.47 | seanbright | it sends a SEGV to the process |
| 22:42.49 | seanbright | heh |
| 22:42.54 | russellb | ha |
| 22:42.57 | russellb | ok, so ... |
| 22:42.59 | russellb | i wouldn't do that. |
| 22:43.01 | seanbright | kill -11 ${PID} |
| 22:43.01 | voxter | hahaha |
| 22:43.06 | voxter | yikes |
| 22:43.08 | russellb | I know why. |
| 22:43.14 | russellb | we weren't getting useful cores with gcore |
| 22:43.18 | seanbright | right |
| 22:43.24 | russellb | when you force it to crash, you get the real state that we really wanted |
| 22:43.33 | seanbright | # the strategy to sending a SEGV signal to the asterisk process, |
| 22:43.38 | seanbright | # and have it 'burn to the ground', leaving behind a core file. |
| 22:43.45 | seanbright | heh. that's reassuring. |
| 22:43.48 | russellb | :) |
| 22:44.00 | russellb | I think we mostly used that script in conjunction with deadlocks |
| 22:44.13 | voxter | well - as much as I dont want to crash a production system, I can probably afford to do it once if it means someone could identify what it is |
| 22:44.16 | russellb | with "core show locks", it hasn't come up anymore .. |
| 22:44.19 | voxter | but at the same time, I will likely just upgrade it anyways. |
| 22:44.31 | russellb | if you're going to upgrade, I don't care to look |
| 22:44.37 | seanbright | ditto |
| 22:46.08 | voxter | hahah, fair enough I suppose :) I guess its mainly my curiosity. maybe its cdr_mysql, but that doesnt explain really why it would only happen every 5-10 minutes, and last 2-3 minutes. and the only cpu usage was in the asterisk process. Aside from that all the box does is hand off calls from either PRI/SIP Peers to my clients via IAX. Alot of them use g729, very few use ulaw. Comparing the number of calls/transcoded calls in high use/low use state sho |
| 22:46.08 | voxter | ws that it is very unlikely to be a call load issue. |
| 22:46.40 | voxter | maybe ill schedule an upgrade tonight though. yay for digging through years of bad dial plan! |
| 22:46.44 | seanbright | shrugs |
| 22:46.49 | seanbright | i only fix spelling errors |
| 22:47.02 | seanbright | russelb -> russellb |
| 22:47.09 | seanbright | all in a days work. |
| 22:47.30 | voxter | :) |
| 22:47.45 | seanbright | even with a core file, it would be hard to isolate. |
| 22:47.52 | seanbright | at least for me |
| 22:48.22 | russellb | it may or may not be obvious |
| 22:48.25 | russellb | no way to know |
| 22:48.33 | russellb | sometimes those problems show themselves, but it's tough |
| 22:48.49 | russellb | anyway, i'm gone |
| 22:48.50 | russellb | cya |
| 22:48.51 | *** part/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 23:24.32 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |