| 00:59.18 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 01:31.37 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-nnuubspdsjyuryap) |
| 01:31.37 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:57.41 | gtjoseph | mjordan: the reason i moved the initializers was that they're now ao2_objects. were you thinking something like AO2_GLOBAL_OBJ_STATIC? |
| 02:06.55 | mjordan | gtjoseph: nope! I probably just need to stop reviewing things right now |
| 02:07.03 | mjordan | gtjoseph: totally blanked that it was ao2_alloc'd. |
| 02:07.33 | gtjoseph | no worries. i'll add the docs though. |
| 02:09.10 | mjordan | I'll give it another look tomorrow when I'm apparently lucid. |
| 02:09.25 | gtjoseph | :) |
| 02:23.31 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-nnuubspdsjyuryap) |
| 02:32.48 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 02:32.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:01.49 | *** join/#asterisk-dev sgalarneau (~Adium@user-24-96-87-214.knology.net) |
| 03:04.56 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:04.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:24.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 03:28.17 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 04:22.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 05:05.54 | *** join/#asterisk-dev snuff-work (~snuffy@1.155.211.84) |
| 05:05.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:16.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 05:56.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 06:33.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 07:10.47 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:58.26 | *** join/#asterisk-dev snuff-work (~snuffy@1.152.211.149) |
| 07:58.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:24.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 09:36.13 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:00.12 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:11.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 10:37.24 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 11:31.33 | *** join/#asterisk-dev reconwireless (uid10170@gateway/web/irccloud.com/x-eojvenksppesobzd) |
| 11:40.53 | *** join/#asterisk-dev jmls (~julian@77.107.171.82) |
| 12:02.00 | *** join/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 12:25.16 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:54.30 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 13:54.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:54.37 | *** part/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 14:11.08 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:11.08 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:15.13 | *** join/#asterisk-dev sliske_ (~sliske_@2607:f0b0:1:6044:9c6:c937:f7d:e27f) |
| 14:17.44 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 14:24.02 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
| 14:31.35 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:32.27 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-shwghsilxnzqsweh) |
| 14:42.03 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-oivfewrreruqbxdi) |
| 14:51.13 | gtjoseph | file: would you be OK with adding the extended fields during contact creation instead of in the for_each_contact? Or even just adding a string field to contact with the parent aor id? |
| 14:51.27 | file | contact may or may not persist |
| 14:52.14 | gtjoseph | that's ok though, if it doesn't persist, no one's going to need to look at it. |
| 14:52.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 14:52.16 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:52.37 | file | I mean it may or may not persist in memory |
| 14:53.00 | file | and extended fields are not persisted out to storage |
| 14:53.27 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-yrlflslfexnqqohi) |
| 14:53.27 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:53.37 | gtjoseph | ah, now i gotcha. |
| 14:54.05 | gtjoseph | ok, i'll create a wrapper structure |
| 14:56.23 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 14:56.28 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:56.28 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:59.20 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
| 15:03.27 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-eucuagwovhuqrqrn) |
| 15:07.12 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-aksmalpcsjxgplsp) |
| 15:18.48 | gtjoseph | after you do a commit to 12, then a block12trunk in trunk, do you have to do a commit in trunk? |
| 15:20.53 | opticron | yes |
| 15:21.07 | opticron | it changes the block property and you have to commit that change |
| 15:21.10 | putnopvut | Honestly, doing the block isn't really that necessary these days. But if you are purposely marking a change as being blocked from trunk, then you can commit to have the branch-12-blocked property updated in trunk. |
| 15:21.30 | gtjoseph | yep i just realized that '.' was showing in svn status. |
| 15:25.04 | kharwell | ARI 'ChannelUserevent' does not map to AMI UserEvent correct? There is currently no way to raise an arbitrary user event in ARI that can be picked up by the other subsystems like AMI? |
| 15:34.25 | mjordan | kharwell: right now it is one way |
| 15:34.35 | mjordan | that is, if you raise a UserEvent through AMI or the dialplan, ARI will receive it |
| 15:34.40 | mjordan | but ARI does not have a way to raise it itself |
| 15:34.44 | mjordan | we have an issue to go do that |
| 15:36.04 | kharwell | mjordan: what event is raised in ARI for an AMI UserEvent? ChannelUserEvent? |
| 15:40.45 | mjordan | most likely, which is something of a bad name... |
| 15:41.04 | mjordan | today, all userevents are associated with channels, but there's no reason why we couldn't have an arbitrary event associated with some other object |
| 15:41.06 | mjordan | oh wellz |
| 15:41.36 | kharwell | so you have to be subscribed to a particular channel to receive it? |
| 15:44.59 | mjordan | If a channel is not in your Stasis application, you have to subscribe to it to receive any events related to it |
| 15:49.03 | mjordan | X-Rob: Do you think you still need ASTERISK-23172 (SIP_URI_OPTIONS) in PJSIP? Or does using PJSIP_HEADER work, in the same way using SIPAddHeader technically works for that option in chan_sip? |
| 15:52.10 | file | originating a channel from inside of ARI and specifying an app should subscribe the app to it |
| 15:57.29 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-lgjpjjndvpunpcii) |
| 15:57.29 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:59.43 | leifmadsen | I feel like this was a discussion :) |
| 16:18.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 16:25.58 | *** join/#asterisk-dev sliske_ (~sliske_@2001:4800:780e:510:6c33:9987:ff05:245f) |
| 16:31.36 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:44.18 | gtjoseph | Is there any script around to post process a refs file? I thought I saw someone reference one earlier this week. |
| 16:46.54 | mjordan | gtjoseph: there's one written in the utils folder |
| 16:46.57 | mjordan | refcounter |
| 16:47.20 | mjordan | it builds lifetime chains for everything however, and unless you have ref_debug enabled globally throughout Asterisk, it will get some things wrong |
| 16:47.36 | gtjoseph | ah, there it is. |
| 17:05.17 | newtonr | mjordan, added your note on refcounter here https://wiki.asterisk.org/wiki/display/AST/Reference+Count+Debugging#ReferenceCountDebugging-Usingrefcountertointerpretoutput . You may want to check it. |
| 17:08.25 | X-Rob | mjordan: PJSIP_HEADER doesn't allow me to add options, does it? |
| 17:08.40 | X-Rob | I can't remember |
| 17:17.11 | mjordan | X-Rob: it would do it however SIPAddHeader did it... |
| 17:17.20 | mjordan | I think there was a mailing list post about that, let me find it |
| 17:20.19 | mjordan | X-Rob: so here's a blast from the past |
| 17:20.25 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-4845 |
| 17:20.39 | mjordan | in fact, it's your comment on it - SIPAddHeader(Call_info: answer-after=0) |
| 17:20.51 | mjordan | Er, Call-Info |
| 17:22.27 | mjordan | I guess the right question is, other than Call-Info for SNOMs - is there any purpose for SIP_URI_OPTIONS? |
| 17:26.30 | gtjoseph | X-Rob: mjordan: What's the issue with options? IIRC when I wrote PJSIP_HEADER you can't modify or delete a header that you didn't previously add. |
| 17:27.10 | gtjoseph | Is that the scenario or are you h=just adding a new header? |
| 17:27.17 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 17:31.45 | X-Rob | mjordan: Um. No. |
| 17:32.07 | X-Rob | It was just the Snoms |
| 17:32.13 | X-Rob | However, that may have changed. |
| 17:53.24 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-fktmaailcstfkapp) |
| 17:58.16 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 18:15.59 | *** part/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 18:28.21 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-gpbhdtqbernztuwr) |
| 18:33.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 18:43.03 | seanbright | i want bamboo to stop sending me e-mails |
| 18:43.08 | seanbright | how can i make that happen? |
| 18:52.10 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@212.34.52.66) |
| 18:52.27 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 18:56.17 | mjordan | X-Rob: with PJSIP_HEADER, you should be able to add a new header |
| 18:57.06 | mjordan | X-Rob: so you should be able to use SET(PJSIP_HEADER(add,Call-Info: answer-after=0)) |
| 18:57.24 | mjordan | hm |
| 18:57.26 | pabelanger | seanbright, https://bamboo.asterisk.org/bamboo/profile/editUserNotifications.action |
| 18:57.27 | mjordan | or not...? |
| 18:58.14 | X-Rob | mjordan: the issue was that I needded to change the TO line. With URI_OPTIONS, anyway. |
| 18:58.31 | mjordan | gtjoseph: so, right now, there's no way to add an option to a request line in PJSIP. I'm trying to figure out if we really need it, or if using PJSIP_HEADER with an alternative SIP header provides the same functionality |
| 18:58.58 | seanbright | pabelanger: thanks |
| 18:59.01 | X-Rob | I don't like PJSIP_HEADER. But that's just me. |
| 18:59.11 | X-Rob | grumbles about people getting off his lawn |
| 18:59.32 | putnopvut | In general you don't like it or for this particular task? |
| 19:00.30 | X-Rob | well, PJSIP_HEADER works like this, according to the docs. Set(PJSIP_HEADER(add,${ARG1})=${ARG2}) |
| 19:00.49 | X-Rob | it didn't seem to be happy just trusting that I wsa giving it a correct header |
| 19:03.07 | X-Rob | https://www.irccloud.com/pastebin/h00SBPrr |
| 19:03.15 | X-Rob | putnopvut: that's what I"m doing now. |
| 19:03.45 | seanbright | the syntax looks wrong |
| 19:04.18 | seanbright | i'm basing that on mjordan's example above |
| 19:04.26 | X-Rob | seanbright: mjordan was wrong 8) |
| 19:04.26 | seanbright | so i might not know what i'm talking about |
| 19:04.32 | seanbright | got it |
| 19:04.35 | mjordan | yup |
| 19:04.37 | mjordan | my example was wrong |
| 19:04.38 | X-Rob | Although, I didn't spend TOO much time trying it the 'old' way |
| 19:04.38 | mjordan | :-P |
| 19:04.54 | seanbright | there i go again thinking that mjordan is perfect |
| 19:04.55 | X-Rob | that would have made my life a bit easier if it had worked |
| 19:05.10 | mjordan | seanbright: I think I would have disabused you of that notion by now... :-P |
| 19:05.52 | putnopvut | So one of the things to keep in mind with the PJSIP_HEADER(add,...) is that it performs the action on the channel that is running the dialplan at the time. So unlike with SIPAddHeader, you can't run it on the inbound channel and affect the outbound channel. |
| 19:06.22 | X-Rob | putnopvut: was that addressed to me? (We've got it sorted) |
| 19:06.55 | putnopvut | X-Rob: yeah, it was. I thought there were issues happening and thought that might be something that wasn't explained clearly. No worries. |
| 19:07.06 | X-Rob | admittedly, I did manage to get 12.1 core dumping when I started using it the other day |
| 19:07.14 | putnopvut | boo |
| 19:07.21 | X-Rob | but I had to do other work, so I switched back to 11 |
| 19:07.26 | X-Rob | I'll poke at 12 again next week |
| 19:09.54 | mjordan | X-Rob: So, assuming PJSIP_HEADER does work, it sounds like having a SIP_URI_OPTIONS channel variable (or some other equivalent thing) isn't really needed |
| 19:10.25 | X-Rob | mjordan: Adding a header works. SIP_URI_OPTIONS is to -alter- the To: line |
| 19:10.30 | X-Rob | is/was |
| 19:10.32 | mjordan | right |
| 19:10.45 | X-Rob | which AFAIK we can't do with pjsip yet |
| 19:11.02 | mjordan | the reason why it was added was originally for the intercom stuff |
| 19:11.13 | mjordan | X-Rob: heh |
| 19:11.24 | mjordan | you can't; I'm trying to figure out if we really need to |
| 19:11.37 | X-Rob | mjordan: Well. I know it was required for snoms |
| 19:11.44 | X-Rob | but that was about it |
| 19:11.52 | X-Rob | I think I have a snom 360 in the shed somewhere |
| 19:12.01 | X-Rob | but I"m guessing you guys woul dhave one lying around to test against |
| 19:12.14 | mjordan | probably in a closet somewhere :-P |
| 19:12.23 | mjordan | with a sign that says "beware of the jaguar" |
| 19:12.38 | Marquis42 | I can certainly think of at least one interoperability scenario (admittedly with an old-and-busted SIP stack) where the would be helpful. |
| 19:12.39 | X-Rob | At the bottom of a broken flight of stairs |
| 19:13.03 | mjordan | Really just prioritizing the PJSIP features at this point - it sounds like this one doesn't need to be at the top of the list |
| 19:13.17 | X-Rob | mjordan: I'd say no, it doesn't. HOWEVER |
| 19:13.20 | Marquis42 | Yeah I wouldn't put that one at the top for sure. |
| 19:13.36 | X-Rob | tm1000: Do you know offhand how many phones need SIP_URI_OPTIONS to autoanswer? |
| 19:17.14 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-whxffoxmyrruuran) |
| 19:55.07 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:01.56 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-dbemuuhqjgicrsnu) |
| 20:20.55 | *** join/#asterisk-dev jemidy (~jemidy@nat/digium/x-oazhrvgycynskcfm) |
| 20:24.45 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 20:26.18 | *** join/#asterisk-dev bford (~bford@nat/digium/x-nsusqxgblebhaoln) |
| 20:28.33 | pabelanger | Where does Asterisk store device state for SIP? |
| 20:28.38 | pabelanger | in memory? |
| 20:29.47 | mjordan | that's kind of a complex question actually |
| 20:29.51 | mjordan | what version? 1.8? |
| 20:30.10 | mjordan | and do you mean device state, or extension state? |
| 20:30.33 | Marquis42 | I assume he means device state since he said for SIP. |
| 20:31.17 | mjordan | just checking ;-) |
| 20:31.33 | Marquis42 | Understood. I'm alos possibly wrong. :) |
| 20:31.51 | pabelanger | Sip device state? not using custom if that is what you are asking |
| 20:32.45 | mjordan | pabelanger: in general, it gets cached in the core |
| 20:32.52 | mjordan | pabelanger: there are times when it is not cached however |
| 20:33.39 | pabelanger | so, the issue I have, asterisk thinks my device is INUSE |
| 20:33.47 | pabelanger | but obviously it is not |
| 20:33.56 | pabelanger | sip show inuse: |
| 20:34.04 | mjordan | pabelanger: with respect to chan_sip, it will only not get cached if it is a guest |
| 20:34.20 | pabelanger | okay, this is a defined peer |
| 20:34.28 | mjordan | pabelanger: there's about 1000 ways that could happen |
| 20:34.33 | pabelanger | so, a reboot should clear it out? |
| 20:34.37 | Marquis42 | mjordan: And only if it's past a certain version of 1.8, right? Wasn't the cacheable stuff added later? |
| 20:34.51 | pabelanger | 4404-1 1/0/0 2147483647 |
| 20:34.52 | mjordan | Marquis42: I'm trusting people aren't running on a vulnerable system of Asterisk ;-) |
| 20:34.58 | pabelanger | that is what sip show inuse reports |
| 20:35.00 | Marquis42 | mjordan: Don't trust that. :) |
| 20:35.10 | mjordan | Marquis42: True, but then I can't help you much |
| 20:35.54 | Marquis42 | nods |
| 20:36.08 | mjordan | pabelanger: so it does the think the peer is inuse |
| 20:36.42 | pabelanger | right |
| 20:37.15 | pabelanger | So, the system was rebooted mid day and I think something got stuck |
| 20:37.20 | pabelanger | and I cannot get it unstack |
| 20:37.24 | pabelanger | unstuck* |
| 20:38.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 20:38.50 | mjordan | pabelanger: you'll want to look at update_call_counter in chan_sip |
| 20:39.41 | mjordan | A lot of things depend on your config. |
| 20:39.49 | mjordan | (By the way: we don't use any of this stuff in chan_pjsip) |
| 20:40.58 | pabelanger | mjordan, okay, so it doesn't use astdb or anything like that |
| 20:42.15 | Marquis42 | AFAIK only Custom device states use the astdb. |
| 20:42.19 | mjordan | chan_sip does not |
| 20:42.20 | pabelanger | right |
| 20:42.35 | mjordan | and the thing showing that something is still in use is chan_sip, and it's basing that off of peer->inUse |
| 20:42.51 | pabelanger | Ya, I see that in the code now |
| 20:47.35 | pabelanger | okay |
| 20:47.38 | pabelanger | I see the issue |
| 20:47.49 | pabelanger | pbx-05-prod*CLI> core show channel SIP/4404-1-00171d49 |
| 20:47.59 | pabelanger | state: Ring |
| 20:48.04 | pabelanger | <PROTECTED> |
| 20:48.13 | Marquis42 | heh, that'll do it yes |
| 20:48.23 | pabelanger | obvious, I am not running SIP session timers |
| 20:48.26 | pabelanger | and show |
| 20:48.30 | pabelanger | should* |
| 20:50.20 | pabelanger | Yup, that was it |
| 20:50.31 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:50.56 | pabelanger | So, note to clients: don't do random reboots of the asterisk PBX or gateway throught out the day |
| 20:51.04 | Marquis42 | true story |
| 20:51.20 | pabelanger | I'd be curious to see if session timers would help with that |
| 20:53.26 | putnopvut | It depends on if there was an active SIP dialog or if there was some other reason for the channel to have gotten "stuck". session timers will make sure that SIP dialogs get torn down, and will signal to the core to hang the channel up when the timer expires. However, it's also possible for the SIP dialog to get torn down properly, but for whatever reason a channel reference is leaked or something, thus resulting in a stuck |
| 20:53.26 | putnopvut | <PROTECTED> |
| 20:53.32 | putnopvut | In other words, enabling session timers may or may not help. |
| 20:57.11 | pabelanger | Cool, thanks for the info. Now to see if my clients phone support them |
| 20:57.49 | pabelanger | i should check out if the information is exposed via AMI (assume it is), then just write a simply service to check once an hour to hang up said channels |
| 21:18.59 | mjordan | so... here's a loaded question. |
| 21:19.10 | mjordan | How do people feel about having old reviews get closed as 'abandoned'? |
| 21:19.26 | Marquis42 | For what value of "old"? |
| 21:19.32 | mjordan | something long |
| 21:19.38 | mjordan | how about 3 - 6 months |
| 21:19.46 | leifmadsen | openstack does that... and I think it's 2 weeks |
| 21:19.58 | leifmadsen | I don't say it needs to be 2 weeks |
| 21:19.58 | Marquis42 | I'm not averse. If there's been no action in that long it probably is abandoned. |
| 21:20.19 | leifmadsen | mjordan: how many reviews would be closed right now at 2 weeks vs 3 months vs 6 months? |
| 21:20.28 | leifmadsen | perhaps there is a happy medium in there somewhere |
| 21:20.36 | leifmadsen | I feel like 60 days is a valid time frame |
| 21:20.38 | mjordan | leifmadsen: no idea. A lot would be closed at 6+ months. |
| 21:20.39 | leifmadsen | 60-90 days |
| 21:20.43 | leifmadsen | oic |
| 21:20.50 | mjordan | we have a bevy of ancient cruft |
| 21:20.52 | leifmadsen | if they are that old, then they are definitely "abandoned" |
| 21:21.00 | file | mjordan, oh heck to the yes |
| 21:21.00 | Marquis42 | agreed |
| 21:21.18 | pabelanger | mjordan, do it. 2 week limit :) |
| 21:21.24 | leifmadsen | what I think would be nice, is if someone created the list of "abandoned" and at least spot checked them to be like, "yeah we just dropped the ball on this" vs "this is not even potentially valid" |
| 21:21.25 | pabelanger | well, |
| 21:21.26 | mjordan | leifmadsen: if you look at just the front page of reviewboard, you get to 60 days right there |
| 21:21.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 21:21.43 | leifmadsen | mjordan: gotcha, so basically there be a lot of shit in the pot |
| 21:21.46 | sgriepentrog | I would think 3 months. 2 is ok too. |
| 21:21.46 | pabelanger | if there is feedback about said patch to do work, no movement in 2 weeks, close it |
| 21:21.50 | mjordan | leifmadsen: it should pretty much always be only if there are open findings |
| 21:22.09 | leifmadsen | mjordan: essentially my answer is, "yes" |
| 21:22.15 | mjordan | keeping in mind, a review can always be reopened |
| 21:22.17 | leifmadsen | I'm in agreement with an abandoned period |
| 21:22.19 | pabelanger | right |
| 21:22.20 | leifmadsen | exactly |
| 21:22.25 | leifmadsen | we do it on the issue tracker |
| 21:22.31 | leifmadsen | I don't see why it can't be extended to the reviewboard |
| 21:22.47 | leifmadsen | I think it's 2 weeks in feedback == closed |
| 21:22.51 | leifmadsen | on issues.asterisk.org |
| 21:23.11 | leifmadsen | keeping a narrow focus I think is a good thing to be honest |
| 21:23.20 | leifmadsen | so I would not be opposed to a somewhat "short" timeframe |
| 21:23.25 | leifmadsen | like 30 days or something |
| 21:25.31 | mjordan | I'll see what's possible through the API, and if it looks doable, shoot an e-mail to -dev |
| 21:28.06 | leifmadsen | +1 |
| 21:34.31 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-btssuwrpqoxgkgpu) |
| 21:39.00 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.159.253) |
| 21:39.10 | file | wait |
| 21:39.14 | file | is that |
| 21:39.17 | file | rmudgett? |
| 21:39.34 | rmudgett | No its an alias impersonating me. |
| 21:39.58 | file | I'd believe that. |
| 21:44.31 | mjordan | passes out |
| 21:57.42 | putnopvut | mjordan passes out what? cookies? flyers? |
| 21:59.19 | mjordan | shock |
| 21:59.27 | putnopvut | declines |
| 21:59.35 | mjordan | rmudgett: did my constant badgering wear you down? |
| 21:59.56 | rmudgett | Finally figured out how to register. |
| 22:00.14 | mjordan | fair enough! |
| 22:09.07 | seanbright | rmudgett graces us |
| 22:09.09 | seanbright | welcome |
| 22:09.36 | rmudgett | waves |
| 22:09.50 | wedhorn | mjordan: quick one from the -dev list if you have a minute |
| 22:11.25 | mjordan | wedhorn: sure |
| 22:11.29 | wedhorn | regarding the pjsip codecs option. It appears that it is basically an alias for allow, so why wouldn't we change other channel drivers to use it as well (and possibly even deprecate allow/disallow) |
| 22:11.44 | mjordan | wedhorn: Oh, I think that'd be great |
| 22:11.56 | wedhorn | is confused |
| 22:12.04 | mjordan | my admittedly 'short' response was that we've done a silly amount of work touching every channel driver over the past year |
| 22:12.15 | mjordan | if someone wants to update a channel driver, that'd be fantastic |
| 22:12.40 | mjordan | So you, may, and igor would probably knock out chan_skinny, chan_ooh323, and chan_unistim |
| 22:12.42 | mjordan | no worries |
| 22:12.44 | wedhorn | okay, cool. Not what I got from your response on -dev ;) |
| 22:12.45 | mjordan | but chan_mobile? |
| 22:13.03 | mjordan | or chan_alsa? Or chan_blech? |
| 22:13.15 | putnopvut | I hate chan_blech |
| 22:13.20 | mjordan | At some point, there's seriously diminishing returns in terms of trying to make all of these consistent. |
| 22:13.25 | Qwell | chan_amonia is where it's at. |
| 22:13.38 | Qwell | I'm missing a letter. m? |
| 22:13.42 | putnopvut | chan_oxi_clan |
| 22:13.47 | mjordan | And if we're going to limit what we do in the future because we have to keep updating channel drivers with no active maintainer, then I'm going to end up having to jettison them. |
| 22:13.49 | putnopvut | yeah, well blech is misisng a letter too |
| 22:13.56 | Qwell | putnopvut: touch |
| 22:14.07 | putnopvut | lawl |
| 22:22.10 | mjordan | wedhorn: clarified. Sorry about that. |
| 22:23.11 | wedhorn | okay, thanks |
| 22:23.15 | seanbright | is david lee on IRC? |
| 22:24.24 | Qwell | seanbright: leedm777 |
| 22:24.25 | file | leedm777 |
| 22:25.06 | seanbright | leedm777: hi |
| 22:25.23 | seanbright | was https://reviewboard.asterisk.org/r/2828 not applicable to Asterisk 11? |
| 22:29.00 | seanbright | well now that i read the code (grin) it appears that it is not applicable |
| 22:29.05 | seanbright | good times |
| 22:30.16 | file | no soup for you |
| 22:34.06 | seanbright | soup is for closers |
| 22:42.58 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-eucuagwovhuqrqrn) |
| 23:34.54 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-yrlflslfexnqqohi) |
| 23:36.27 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 23:47.50 | *** join/#asterisk-dev snuff-work (~snuffy@1.154.161.59) |
| 23:47.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:58.19 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |