01:09.27 | *** join/#asterisk-doc eliel (~eliels@186.18.108.106) |
04:44.59 | *** join/#asterisk-doc snuff-home2 (~snuffy@203-219-29-182.tpgi.com.au) |
05:06.04 | *** join/#asterisk-doc snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
05:17.22 | *** join/#asterisk-doc snuff-home2 (~snuffy@203-219-29-182.tpgi.com.au) |
05:26.46 | *** join/#asterisk-doc snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
05:51.39 | *** join/#asterisk-doc oej (~olle@ns.webway.se) |
06:38.07 | *** join/#asterisk-doc oej (~olle@ns.webway.se) |
07:03.38 | *** join/#asterisk-doc jsmith-away (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
07:03.38 | *** mode/#asterisk-doc [+o jsmith-away] by ChanServ |
07:09.20 | *** join/#asterisk-doc oej (~olle@ns.webway.se) |
08:47.24 | *** join/#asterisk-doc fors1 (~forsen@pat-tdc.opera.com) |
08:47.24 | *** join/#asterisk-doc DocAwesome (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
08:47.24 | *** mode/#asterisk-doc [+o DocAwesome] by anthony.freenode.net |
11:24.32 | *** join/#asterisk-doc eliel (~eliels@201.234.94.226) |
11:31.03 | *** join/#asterisk-doc leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
11:31.03 | *** mode/#asterisk-doc [+o leifmadsen] by ChanServ |
12:18.50 | *** join/#asterisk-doc Andrew_M_ (~1867ea4a@gateway/web/freenode/x-cninircexucibjjy) |
12:19.17 | Andrew_M_ | Good morning all! |
14:14.07 | Andrew_M_ | * |
14:50.02 | *** join/#asterisk-doc seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
14:51.16 | *** join/#asterisk-doc eliel (~eliels@201.234.94.226) |
15:23.39 | *** join/#asterisk-doc corretico (~laguilar@201.201.46.106) |
17:02.28 | jsmith | finally stumbles into IRC |
17:17.54 | *** join/#asterisk-doc jasonjjohnsonjr (~jasonjjoh@asa1.jsmc.org) |
17:21.57 | jasonjjohnsonjr | Hey guys. This is probably more of a Cisco question but I will ask anyway. I have a 7975 phone that I am trying to register. I can register it to a local asterisk box but when I try and register to a remote asterisk server I am getting Status: 401 Unauthorized messages back. |
17:24.38 | jasonjjohnsonjr | I am thinking it looks like the issue may be the server is looking for the realm as "asterisk" but the phone is sending it as the proxy setting which is the IP. I don't know why it would work locally if that were the case though. |
17:27.05 | jsmith | jasonjjohnsonjr: Are you registering to an IP address, or to a FQDN? |
17:27.18 | jsmith | jasonjjohnsonjr: Is the firewall a Cisco PIX by chance? |
17:28.12 | jasonjjohnsonjr | IP address and yeah a pix. Really an ASA5510 but close enough |
17:28.45 | jsmith | Most likely, the ASA is rewriting the IP address in the SIP Request URI, causing the authentication to fail |
17:29.01 | jsmith | Try registering to a FQDN (that points at the remote box), or fix your ASA |
17:30.05 | jasonjjohnsonjr | Would the 7975 be treated differently by the ASA than the 7940 model phones were are already using? |
17:30.15 | jasonjjohnsonjr | I will try the fqdn idea though |
17:30.59 | jsmith | Nope... they should work exactly the same with regards to SIP authentication, I would think |
17:31.09 | jsmith | doesn't have a 7975 :-( |
17:31.51 | jasonjjohnsonjr | At this point I am so sick of this one I will ship it to you ;-) |
17:32.48 | jasonjjohnsonjr | The 7975 models use the xml config files instead of the plain text files used by the 7940s we have been using but if it works local I don't understand the difference. |
17:36.54 | jasonjjohnsonjr | The remote box is running 1.6.0.17 and the local box is running 1.6.0.21. Could that make a difference to the registration? |
17:37.10 | jsmith | Shouldn't |
17:37.24 | jasonjjohnsonjr | k |
18:57.42 | *** join/#asterisk-doc parra (~parra@95.120.37.64) |
18:58.04 | parra | hi guys |
18:58.22 | parra | someone can help me? |
19:00.16 | jsmith | parra: What's your question? |
19:00.22 | jsmith | ~ask |
19:00.23 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
19:00.39 | parra | i want to know about the community roles in asterisk project |
19:01.06 | parra | i can't find it on the web, i was all the day searching it but the link is broken |
19:01.09 | jsmith | First of all, we welcome community involvement |
19:01.19 | jsmith | There are no fixed "roles" per se |
19:01.43 | jsmith | We simply encourage people (whether Digium employees or from the community at large) to participate |
19:02.04 | parra | yeah but for example, you have bug marshals |
19:02.08 | parra | this is a role |
19:02.18 | parra | isn't it? |
19:02.25 | jsmith | Well, I don't know that we have any *formal* procedure for becoming a bug marshall |
19:02.46 | jsmith | Basically anybody that wants to help out and puts forth some effort can become a marshall |
19:03.03 | jsmith | You should talk to leifmadsen about that, as he's the semi-official bug marshall |
19:03.22 | jsmith | leifmadsen: (I'm assuming that's true... are you the official marshall, or just semi-official?) |
19:03.44 | leifmadsen | I'm an official bug marshal yes :) |
19:04.06 | leifmadsen | which means absolutely nothing other than I have bug marshaling rights, just like several other people :) |
19:04.14 | leifmadsen | parra: what can I do for ya? |
19:04.15 | parra | I'm studying a master of free software at university, and I have to document your project |
19:04.39 | leifmadsen | we welcome any and all documentation, even if it is just a documentation about us :) |
19:04.49 | parra | I choose it because it seems to be well organised |
19:04.50 | leifmadsen | s/a documentation/documentation |
19:04.57 | leifmadsen | we fake it good :D |
19:05.03 | leifmadsen | how can I be of assistance? |
19:05.34 | parra | I was looking for the community roles in the web but the link is broken |
19:05.45 | parra | perhaps you know something about this |
19:05.55 | leifmadsen | and no, there isn't any formal procedure to becoming a bug marshal other than to show interest and to start getting involved. Once involved, we can up someones privileges so they can actually change bug status etc. |
19:06.03 | leifmadsen | which link is it? that should get fixed |
19:06.25 | leifmadsen | (a lot of links got broken in the transition from the old site to the new site -- don't get me started on that :)) |
19:06.28 | parra | http://www.asterisk.org/developers/community-roles |
19:06.31 | leifmadsen | I thought I had found most of them |
19:06.37 | leifmadsen | hold please! |
19:06.40 | parra | yeah i've read it |
19:07.25 | parra | like this one too: http://www.asterisk.org/developers/patch-howto |
19:08.08 | leifmadsen | wow, I can't believe we still have broken links on this site |
19:08.25 | leifmadsen | thanks for pointing them out -- be back with you in a few moments after I find the documentation and fix the links |
19:08.40 | parra | a lot of thanks |
19:09.10 | parra | I will wait, it's interesting to speak with people involved in projects like yours |
19:09.14 | leifmadsen | wow, actually I don't like the old page that should link to... |
19:09.29 | leifmadsen | that needs to be badly updated, which means I need to write it from scratch |
19:09.51 | leifmadsen | parra: I'm going to create an issue for myself to get that fixed within the next 30 days or so |
19:09.57 | parra | I understand |
19:10.13 | leifmadsen | perhaps you can help with some of that by asking questions and me answering them (I will then take notes and add them to an outline) |
19:11.00 | parra | ok |
19:12.02 | parra | so... can you tell me if these are the steps for adding a patch to SVN repository? |
19:12.25 | parra | 1. do the patch working with last version of trunk |
19:13.00 | parra | 2. test the patch exhaustively with other developers in #asterisk-dev |
19:13.29 | parra | 3. open a new issue called "[patch] blah blah blah" |
19:14.02 | parra | 4. bug marshall do a revision of code and tests the patch |
19:14.56 | parra | 5. bug marshall speaks with other bug marshalls and decide if it's a feature or bug necessary for a minimum of users |
19:15.17 | parra | 6. if it's right, the patch is added to trunk svn repository |
19:15.32 | parra | the end |
19:15.49 | leifmadsen | almost, pretty close |
19:15.57 | leifmadsen | 1. correct |
19:16.22 | leifmadsen | 2. test the patch extensively (but not specifically with developers in #asterisk-dev -- you can ask questions from them there if you are having issues, or using the asterisk-dev mailing list) |
19:17.02 | leifmadsen | 3. Open a new issue with a verbose description of what the patch resolves (new feature, fixes a bug, adds documentation, etc...). The need to add [patch] is unnecessary as that is done automatically when the patch is attached |
19:17.28 | leifmadsen | 4. (if this is a new patch, then you must actually sign the electronic license prior to uploading the patch. This only needs to be done once.) |
19:19.00 | leifmadsen | 5. bug marshals will triage the issue by fixing summary titles (if necessary), asking for additional information (if necessary), request that you gather additional testing if possible from other community members. Bug marshals may perform testing, but that is not their duty. The duty of the bug marshal is generally just to make sure an issue has enough information available so that when a developer looks at the issue |
19:19.00 | leifmadsen | they have everything they need ot move it forward. |
19:20.00 | leifmadsen | 6. bug marshals can typically tell if something is a feature or a bug based on the description of the issue being filed. New features can only go into trunk. Bug fixes can go into one or more branches if applicable. |
19:20.59 | leifmadsen | 7. As the primary bug marshal, I will import issues into the Digium internal issue tracker where issues are prioritized and assigned to Digium developers every 28 days (or so) during our "sprint". These issues are then resolved (ideally) by the developer it is assigned to. |
19:21.45 | leifmadsen | 8. Issues may also be resolved by community developers who have commit access. There is no time line or mandate to dictate when or how much work they must perform. Any issues resolved by a community developer are done on their own time. |
19:22.17 | leifmadsen | 9. At the end of a sprint, all issues resolved will be in the branches, from which release candidates are made, and eventually moved toward releases |
19:23.11 | leifmadsen | (going back to your 6. statement -- issues may be added to 1 or more branches including trunk. All issues make their way to trunk unless it has already been previously resolved there in some other fashion. Bug fixes may only apply to certain branches for example.) |
19:23.15 | leifmadsen | that's it! |
19:23.33 | parra | wow, it's amazing |
19:24.11 | parra | why do you have to add the issues to digium issue tracker? |
19:24.32 | parra | the can see the issues in the "normal" tracker |
19:24.38 | leifmadsen | note that these processes have been developed over time, and the sprint stuff is a fairly recent (about 6-8 months) addition. Previously, Digium developers would just pick from a myriad of issues whatever they felt like. Now issues are prioritized and assigned to developers based on expected number of working hours in a sprint session. |
19:25.39 | leifmadsen | https://issues.asterisk.org is the Open Source Asterisk Community tracker. These issues are available to any developer or person to comment on or work with. The importing of issues is only done for Digium developer time tracking. All commenting and work is actually done on the public tracker, so no information is hidden from the community. |
19:26.31 | leifmadsen | Importing of issues is only done once an issue has been triaged and is deemed to have enough information for a developer to start working on it. By importing it, we have a special application that allows us to rate the issues fairly and then assign the expected hours to resolve the issues to developers. |
19:26.39 | parra | but the digium developers have some privileges deciding some issues? |
19:26.44 | leifmadsen | not really |
19:27.57 | parra | then I understand that digium guys it's a team inside asterisk developers community |
19:28.12 | parra | but nothing special |
19:28.45 | leifmadsen | the developers themselves do not do the priortization. The Asterisk Open Source Community Relations Manager does that -- he is the ambassador of the open source community, and rates the issue by giving it a number that says, "yes, this is important to resolve". Then the lead developer gives a rating about how much work is involved (those issues with patches typically have less "engineering effort"). With that number c |
19:28.45 | leifmadsen | ombined (priority to resolve + effort required) issues can be fairly assigned to developers once a month. |
19:29.19 | parra | cool |
19:29.25 | leifmadsen | John Todd is the current Asterisk Community Relations person (previously it was Jared Smith who is now focusing on Training. He previously did both jobs) |
19:29.43 | leifmadsen | if you go back in time, you will see that John Todd is a highly respected community relations person |
19:30.02 | parra | I think I read something about him on the web |
19:30.10 | leifmadsen | so he has been a good choice for that particular job (not that Jared wasn't, because he did a great job as well! He was just doing 2 jobs at once, and now he can focus on training) |
19:30.21 | leifmadsen | yes you likely have. He has been involved with Asterisk for many years. |
19:31.10 | parra | you know all about asterisk :) |
19:31.16 | leifmadsen | If you look at the RoadMap section of the Asterisk issue tracker, you can see which issues have been assigned to developers during the current sprint, and which version of Asterisk they will be in. |
19:31.21 | leifmadsen | I know a few things :) |
19:31.40 | leifmadsen | I'm the Asterisk Release Manager (previously Russell Bryant who is now the lead developer) |
19:32.29 | leifmadsen | I took over the job of doing Asterisk releases from Russell about a year or so ago |
19:33.06 | parra | I think this is the answer to my question of community roles I was looking for |
19:33.12 | leifmadsen | we've since implemented several methods of trying to tame the 600+ open issues we have at any given time and to maximize productivity. Russell has also taken the lead on getting and automated testing framework going which has proven successful thus far |
19:33.16 | leifmadsen | http://bamboo.asterisk.org |
19:33.55 | leifmadsen | bamboo is a system that performs both unit tests (tests inside the code) and external tests (tests external of the code) to limit regressions introduced by other code |
19:34.09 | parra | release manager, lead developer, Asterisk Community Relations ... |
19:35.12 | parra | wow! so cool this system of unit tests |
19:35.56 | leifmadsen | yep :) tests are triggered on many different types of system (linux, freebsd, solaris, etc...) each time a commit is made :) |
19:36.13 | leifmadsen | its fairly new so we're working out the kinks, but several tests have already been developed |
19:37.39 | parra | it emulates all the different OS? |
19:37.55 | parra | and architectures |
19:39.53 | leifmadsen | actually, they are the different OS systems. Some virtual machines and some community sponsored servers are running various versions of Linux, FreeBSD and Solaris with different architectures (32 bit and 64 bit). These are all individual "build slaves" that are triggered to start building by the centralized bamboo process |
19:40.15 | leifmadsen | so bamboo doesn't simulate anything -- it just triggers systems with various OS and distros installed on them to run the tests |
19:40.25 | leifmadsen | bamboo is just the coordinator |
19:40.31 | leifmadsen | the conductor if you will :) |
19:40.43 | leifmadsen | and the various build slaves make up the orchestra |
19:40.49 | parra | I see, very interesting monitor |
19:41.29 | leifmadsen | whenever a commit is introduced the causes a test to fail, developers are notified stating something they committed failed a test. They are then expected to resolve the change so the test passes again. |
19:42.20 | leifmadsen | Another interesting utility we've introduced into development recently is ReviewBoard (http://reviewboard.asterisk.org) -- this is a system that allows developers to post their patches for peer review prior to them being committed which allows the quality of the code going into Asterisk to be much much better. |
19:43.18 | leifmadsen | Issues the original developer may not have thought of can be reviewed by other developers, and issues caught before they are even committed to Asterisk. Previously those issues may not have been found until weeks, months, or years later. So the quality of code is greatly enhanced even before it goes into Asterisk and before a bug is filed. |
19:43.43 | parra | I saw it this afternoon |
19:44.10 | leifmadsen | I think that's pretty much most of the things in the development process. |
19:44.13 | parra | this is important, the more you have good code before, the less you have to work after |
19:44.34 | leifmadsen | So we have: 1) Mantis (bug tracker), ReviewBoard, Sprints, and automated testing via Bamboo |
19:44.38 | leifmadsen | exactly |
19:44.59 | leifmadsen | So we have: 1) Mantis (bug tracker), 2) ReviewBoard, 3) Sprints, and 4) automated testing via Bamboo |
19:45.02 | leifmadsen | (thats what I meant) |
19:45.22 | parra | very good |
19:45.25 | leifmadsen | anyways, I'm not sure I've really discussed "community roles" -- that is more the development process |
19:45.34 | leifmadsen | do you have any questions about particular roles of the community? |
19:45.41 | parra | oh sure |
19:45.55 | parra | like your role as release manager |
19:46.07 | leifmadsen | (btw: I'd love to read your document when you finish it) |
19:46.10 | parra | or russel bryant as lead developer |
19:46.22 | parra | sure |
19:46.40 | parra | it's a little document, with general points but it's a wiki |
19:47.54 | parra | if you want I can send you a PDF, but it's in catalan |
19:48.02 | parra | because i'm from barcelona |
19:49.14 | leifmadsen | OK, so my role as the release manager is to make sure asterisk releases go out in a standard fashion, are signed electronically by other developers, to write release announcements, etc. That role makes sense because I'm the primary bug marshal, so I look at all issues that go through the issue tracker, triage those issues, import triaged (i.e. real bugs) into the sprint system, and to make sure issues move forward whe |
19:49.15 | leifmadsen | re possible. When those issues are then prioritized and assigned to developers, I place them into the RoadMap on the issue tracker, and when those issues are all completed at the end of the sprint, I create release candidates. I watch the issue tracker to make sure major regressions are not found. If they are, then they become blocking issues for the next release, and those must be resolved prior to a full release bei |
19:49.15 | leifmadsen | ng made. |
19:50.47 | leifmadsen | Russell as the lead developer manages the other asterisk developers (primarily the digium ones) but also interacts with the community and helps steer people along by doing code reviews and helping determine the engineering effort required to resolve issues. He also setup bamboo and setup many of the new development tools I spoke about earlier (like reviewboard, bamboo, etc...) |
19:52.12 | parra | this is all i've done by the moment |
19:52.20 | leifmadsen | All developers work together (whether from Digium or from the community) to resolve issues and to make sure they follow the general flow of: Issue entered into Mantis, Issue Tested, Issues Reviewed (typically on reviewboard), Issue Committed, Issue Merged to appropriate branches, Addition of Unit Tests and External Tests, and then eventually made into a Release. |
19:52.27 | leifmadsen | not a problem -- you can always ping me about it later |
19:52.30 | parra | I have to add all the information you are giving to mi |
19:52.37 | leifmadsen | I might not be ale to accept it very easily via DCC :) |
19:52.48 | leifmadsen | that's fine -- send me a copy whenever you are done |
19:52.51 | leifmadsen | lmadsen@digium.com |
19:53.02 | parra | ah ok |
19:53.08 | parra | well |
19:53.59 | parra | and |
19:54.10 | parra | John Todd as relations manager |
19:54.35 | parra | or there's some role like these thaht I still doesn't know? |
19:54.43 | parra | that* |
19:55.18 | leifmadsen | Ah yes. So John Todd as the relations manager monitors mailing lists and interacts with the community on behalf of Digium, and acts on behalf of the Community to Digium. He is the gateway between Digium and the Community to make sure the interests of both entities are met and that communications are flowing between them. |
19:55.58 | leifmadsen | He may be able to state it more succinctly than myself, but that is generally what he does. |
19:57.53 | parra | It's amazing for me how all you work together |
19:59.18 | leifmadsen | we work hard on it :) |
19:59.37 | leifmadsen | it amazes me sometimes too |
19:59.49 | parra | I will try to add tomorrow all the information you gave to me, it's too interessting |
20:00.04 | leifmadsen | sounds good! let me know if you have any other questions |
20:00.07 | leifmadsen | I must get back to work now :) |
20:00.09 | parra | and I must give you a lot of thanks |
20:00.24 | parra | not by the moment |
20:00.33 | parra | it's a lot of information so useful |
20:01.16 | parra | it's a pleasure to find someone to ask and get answers |
20:02.06 | parra | maybe I get back someday before next tuesday to get more information :) |
20:02.40 | leifmadsen | not a problem, I'm here all the time :) |
20:02.47 | leifmadsen | you caught me at a good time :) |
20:03.25 | parra | thanks a lot leifmadsen, and thanks also to jsmith |
20:03.32 | parra | and now, good work to all |
20:03.35 | jsmith | No worries! |
20:03.43 | parra | good bye guys! |
20:03.47 | parra | thanks! |
20:04.15 | leifmadsen | peas out! :) |
20:04.31 | parra | heheheh |
20:44.54 | jasonjjohnsonjr | ok wow I just archived off everything I have missed since lunch to read over. Leif that was alot of info |
20:45.08 | leifmadsen | jasonjjohnsonjr: it was a bit :) |
20:46.22 | jasonjjohnsonjr | jsmith: I have been doing some research on my 7975 issue and it looks like it does not support symmetrical nat. |
20:47.02 | jasonjjohnsonjr | It is only listening for sip responses on 5060 even though it sends out a different port |
23:07.29 | *** join/#asterisk-doc snuff-home2 (~snuffy@203-219-29-182.tpgi.com.au) |
23:35.22 | *** join/#asterisk-doc seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
23:35.48 | *** join/#asterisk-doc Alric (~nbowyer@75.142.179.232) |