Greetings,

Shortly after the release of Asterisk 1.8, we had a developer meeting
and discussed some of the projects that people would like to see in
Asterisk 1.10 [1]. We discussed the schedule there a bit, as well. Now
that Asterisk 1.8 has settled down and we are well into the development
cycle for Asterisk 1.10, it is a good time to revisit the plans for the
next release.

At Digium, the biggest thing we have been working on for 1.10 so far is
replacing the media infrastructure in Asterisk. Most of the critical
and invasive plumbing work is done and has been merged into trunk. Next
we’re looking at building up some features on top of that, such as
adding more codecs, enhancing ConfBridge() to support additional
sampling rates (HD conferencing), adding features that exist in
MeetMe() but not ConfBridge(), and enhancing codec negotiation.

Of course, many others have been working on new developments as well. I
would encourage you to respond if you’d like to provide an update on
some new things that you’re working on.

We would like to release Asterisk 1.10 roughly a year after Asterisk
1.8. This will be a standard release, not LTS [2]. To have the release
out in the October time frame, we need to branch off 1.10 (feature
freeze) at the end of June. At that point we will begin the beta and RC
process. If you’re working on new development projects that you would
like to get into Asterisk 1.10, please keep this timeline in mind.

As always, comments and questions are welcome.

Thanks,

[1] https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2010
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

–
Russell Bryant

A while back, I posted a message about an effort to improve automated testing in the Asterisk project. I wanted to give an update on how that project has progressed for those that have not been following along very closely.

We started using Bamboo as a continuous integration tool, which you can find running at http://bamboo.asterisk.org/. Note that some of the pass/fail statistics on there are a bit skewed, as the Bamboo server was just rebuilt and things were failing as everything was put back together.

A lot of really good automated test cases have been developed, and more are constantly being added. There are currently 85 test cases that run against Asterisk trunk after every change to the code. While some tests are small in scope, many of them cover significant call scenarios, such as various methods of doing transfers and call parking.

I apologize for the previous flood of Bamboo emails to the -dev list. I now have a new mailing list created for those that would like to subscribe to those messages.

http://lists.digium.com/mailman/listinfo/test-results

Additionally, one of the latest updates to our Bamboo setup is automated testing code coverage analysis. It will tell us exactly what code ran as a result of our automated test cases. It provides a good metric to start using to help identify areas of Asterisk that are in need of more test cases. You can find the code coverage reports for the latest builds of Asterisk trunk and 1.8 on Linux in the artifacts tab when viewing the details of a build.

http://bamboo.asterisk.org/browse/AST-TRUNK/latest

I’m proud of the progress we have made so far and am excited to continue aggressive development of automated test cases for Asterisk. The tests we have are already catching problems on a regular basis. The resulting quality improvements make the job of the development team easier, as well as result in a better experience for end users.

If you’re looking for a way to contribute to Asterisk and you are more comfortable writing scripts instead of C code, then the external test suite is a great way to get involved and help out.

Thank you all for your continued support of Asterisk!

Best Regards,

–
Russell Bryant
Digium, Inc. | Engineering Manager, Open Source Software
445 Jan Davis Drive NW – Huntsville, AL 35806 – USA
jabber: rbryant@digium.com -=- skype: russell-bryant
www.digium.com -=- www.asterisk.org -=- blogs.asterisk.org

Greetings,

I think we can do a much better job at testing within the Asterisk project and I suspect you do, too. The vast install base and wide variety of uses gets us very good feedback. However, it is clear that we can do better within the development community at improving the quality of the code before it makes it out in any type of release (beta, RC, or full release).

I would like to propose that we adopt an automated testing approach as a part of our development process. There are 4 pieces to this:

1. Testing with our eyes
2. Bottom-Up testing using unit tests within Asterisk
3. Top-Down testing using an external test suite
4. Tests running constantly using a continuous integration framework

While this isn’t automated testing, it is too valuable not to mention. One of the most effective ways of finding bugs in code is by peer code review. We see this more and more as we continue to increase our usage of ReviewBoard for peer review before changes are merged. It’s rare that a change goes in as the first proposed patch that goes on ReviewBoard. While it has never been a hard rule, it is strongly encouraged that every committer to seek a sign-off from at least one other committer via ReviewBoard for _every_ non-trivial change.

https://reviewboard.asterisk.org/

For unit testing, we have a new API in Asterisk trunk for writing unit tests within the code. We’re up to 20 unit tests. Writing these tests has already found multiple bugs and running them continuously has caught one regression before it made it into a release.

See include/asterisk/test.h

The beginnings of an external test suite have been created. There is still design work to do, but hopefully it will begin to be populated with tests soon. In general, though, this will become a suite of tests that can use whatever external tools are necessary to verify Asterisk functionality. There is a README.txt that documents what is there so far.

$ svn co http://svn.digium.com/svn/testsuite/asterisk/trunk

On the continuous integration front, we have been using buildbot for a long time for doing compilation on various systems. It’s time that we extend our continuous integration approach to not only compile Asterisk, but also run regression tests. After evaluating some different options, Bamboo has been installed and configured for our use. So far, it is compiling all release branches of Asterisk. For Asterisk trunk, it is running all of the unit tests after every change to the code. The results of the tests are integrated into the application.

Bamboo – The Asterisk Project

The only build slave right now is Linux. This will be extended to other operating systems. If you would be interested in providing a build slave and assisting with its maintenance, please talk to me. We can configure up to 25 build slaves (“remote agents” in Bamboo terminology).

If you have commit access, you are strongly encouraged to sign up for an account on bamboo.asterisk.org and associate your account with your svn username. That way, bamboo can notify you by email and/or jabber if there any problems associated with changes that you make.

As you work on changes to the Asterisk code, you should consider this approach to testing along side your development. If there is a unit test you could write to help prove your code works or prevent a bug from showing up again, then please write one! If there is an external test you could write to help verify some piece of functionality you are using continues to work precisely as expected, then let’s figure out how to get that into the test suite. This kind of testing not only prevents regressions but it also guarantees that expected behavior will remain intact across releases.

I am excited about what this effort can do for the quality of Asterisk in the long term, and I hope you are, too. I look forward to your feedback on the approach as well as participation in the development of our testing infrastructure.

Thanks,

–
Russell Bryant
Digium, Inc. | Engineering Manager, Open Source Software
445 Jan Davis Drive NW – Huntsville, AL 35806 – USA
www.digium.com -=- www.asterisk.org -=- blogs.asterisk.org

Congratulations to all accepted students!

Today, I released a module that allows you to insert static into your phone calls. Are you looking for something to help you get off of annoying phone calls? If so, this module may be for you.

The code is posted for public review and download on the Asterisk project code review site, reviewboard.

Enjoy!

—

[Note: Please pass this note along to European developers who you may know are not actively scanning the -dev list!]

The European Asterisk development community may be the largest number of active participants on a per-continent basis, depending on how the measurement is done. There have been a few meetings of Asterisk developers in Europe over the last ten years, but recently there has not been a planned get-together of developers like has been arranged at AstriDevCon (following Astricon) in North America. It is too infrequent that Digium engineering members get to see some of those participants, and also we’d like to encourage the development community by getting everyone together once in a while to meet and talk in a way that is more personable than email, IRC, or by voice alone. Therefore, I’d like to announce that there will be an Asterisk Developer European Meet-Up held in Rostock, Germany on May 2nd and 3rd for the purposes of meeting old friends, introductions to new coders, and getting some good work done towards furthering Asterisk open-source development.

The meeting will be held immediately before AMOOCON on the Saturday/Sunday before the conference. We’ve been given a room and Internet connectivity for the purposes of having the meet-up, and I suspect there are some good restaurants and bars in the area which might be suitable for post-coding discussion as well.

There is a small group who I’ve already been in touch with on this, and in order to get a good quorum of developers we’d like to open up the session to a wider audience of development participants. This is really for people who write core Asterisk code – the subjects covered will not be applicable to “user” portions of Asterisk, so please respond only if you’re actively writing code within the Asterisk project. If you’d like more general topics, the AMOOCON conference will cover a broader range of VoIP areas. You are encouraged to sign up for the AMOOCON (http://www.amoocon.de/) event which is happening right after the meet-up and is a paid event, but keep in mind the Asterisk Developer European Meet-Up is free to participants. There will be a good handful of attendees from Digium – Kevin, Russell, and perhaps other as-yet-undecided engineering staff, but it’s your participation that is what is going to make the meeting productive – we look forward to hearing from you!

Please send your interest to me and I’ll add you to the list of attendees.

What: Asterisk Developer European Meet-Up
When: May 2-3, 2009
Where: Rostock, Germany
Why: Coding, discussion, testing, bugfixing, drinking, etc.
Who: Replies to jtodd at digium.com

For potential students interested in working with us, our ideas list is here, and feel free to contact me directly at russell (AT) digium (DOT) com if you have any questions.

To get a head start on testing Asterisk 1.6.2 with R2 support, check out the code from the 1.6.2 branch:
$ svn co http://svn.digium.com/svn/asterisk/branches/1.6.2 asterisk-1.6.2

Before compiling Asterisk, you will need to compile and install LibOpenR2.

Thank you very much to Moises Silva (Moy), who worked very hard to write LibOpenR2 and bring this functionality to Asterisk!

——————————————————–
Greetings,

The Asterisk project participated in the Google Summer of Code program in 2005, but has not since then. I would like to apply again this year.  I think it is an amazing opportunity to reach out to new developers and get some code written that we all want done, but have not had a chance to get to.

http://code.google.com/soc/

If we want to make this happen, we have a couple of things that we need to come up with as soon as possible. Mentoring organizations must complete their application for the program this week.

1) We need to determine who is willing to serve as a mentor from the Asterisk project. Mentors will be paired up with a student and will provide guidance to help the student bring their project to completion.  Without commitments from mentors, we can not participate in the program.

Obviously, an appropriate pairing of a mentor to a student is important.  It’s acceptable to say, “I am willing to be a mentor, provided that it is for a student working on a project in my area of expertise.”

If you think you would be interested, please let me know! Feel free to respond on this list, or to me directly.

2) We must build a suggested project list. When students apply for the program, they can submit a proposal for implementing one of our suggested projects, or another project of their choosing. Projects for this list should be appropriate in scope for a college student not yet familiar with the code base to implement in a Summer.

I’m going to create a file in svn to maintain our project ideas list:

- svn/asterisk/trunk/doc/google-soc2009-ideas.txt

To kick of the list of ideas, here are a couple of high level thoughts:

a) I think we could break up the “PineMango” project into multiple suggested projects.

b) John Todd and others had some great ideas regarding security in Asterisk at the last developer conference that could be turned into suggested projects.

If you have some thoughts about other projects to add to the list, again, please let me know, and I’ll add them to our ideas list.

Thanks!

–
Russell Bryant
Digium, Inc. | Senior Software Engineer, Open Source Team Lead
445 Jan Davis Drive NW – Huntsville, AL 35806 – USA
Check us out at: www.digium.com & www.asterisk.org