asteriskteam September 19th, 2011

Recently, we were notified that the mechanism included in our Asterisk
source code releases to download and build support for the iLBC codec
had stopped working correctly; a little investigation revealed that this
occurred because of some changes on the ilbcfreeware.org website. These
changes occurred as result of Google’s acquisition of GIPS, who produced
(and provided licenses for) the iLBC codec.

We’ve determined that the change necessary to fix Asterisk’s iLBC build
process is rather trivial, and so we’re planning to make that change in
Asterisk 1.8.7.0-rc2, and subsequently in 1.8.7.0. We are not planning
on making new releases of Asterisk 1.4 and Asterisk 1.6.2, since they
are in security-maintenance mode and this is not a security issue. Users
who wish to make the same change on their own to their copies of those
versions are of course welcome to do so.

As part of the process of determining what had broken here, we also
became aware that the ilbcfreeware.org website no longer offers the iLBC
license agreement it used to offer; this agreement was required by the
iLBC licensors (GIPS) in order for users to safely distribute and use
iLBC (and this is why the Asterisk project does not include the iLBC
source code directly with Asterisk). The removal of this license
agreement also occurred as a result of the Google acquisition, but as of
this moment no alternative has been made available for those who wish to
use the iLBC source code published in RFC 3951 (which Asterisk uses).

Google does have an alternative implementation of iLBC available as part
of the WebRTC project, with a license that is compatible with Asterisk
(and does not require written agreements from end users), but the
codec_ilbc module in Asterisk cannot be built against the WebRTC
implementation of iLBC. Until such time as we have an improved version
of codec_ilbc, Asterisk users will have to continue using the RFC 3951
iLBC source code.

Unfortunately, that leaves Asterisk users in a bit of a bind; if they
had already signed and sent in the GIPS iLBC license agreement, we
believe they can continue to safely use the existing iLBC
implementation. New users, though, do not have the option of agreeing to
a license agreement that would allow them to use the RFC 3951 iLBC
source code, as there is no mechanism to do that currently available.
We’ve contacted Google and they are aware of the dilemma, and have said
that they will address it, but we don’t have a timeframe for when an
alternative license mechanism will be available.

In summary, if you are a user of Asterisk and iLBC together, and you’ve
already executed a license agreement with GIPS, we believe you can
continue using iLBC with Asterisk. If you are a user of Asterisk and
iLBC together, but you had not executed a license agreement with GIPS,
we encourage you to research the situation and consult with your own
legal representatives to determine what actions you may want to take (or
avoid taking).

• Information
• Comments Off

Leif Madsen September 2nd, 2010

There have been several questions lately asking about how the process of
Asterisk bug releases take place, so this blog post is to help inform you about
the process utilized for making bug fix releases of Asterisk.

Sprints

Digium’s Asterisk development team uses a Scrum based development process.
Development occurs in iterations referred to as a sprint. Our sprints are 20
weekdays in length. A prioritized backlog of development projects is maintained
and constantly updated, which includes all issues from issues.asterisk.org along
side other new development projects. At the beginning of each sprint, items
from the prioritized backlog are assigned to developers to work on during the
sprint.

The issues in mantis are then updated to be assigned to a target version on the
roadmap. You can see the items targeted for completion in the sprint by
visiting https://issues.asterisk.org/roadmap_page.php

As issues during the sprint are completed, the issues are closed and the
fixed merged into the various branches of Asterisk (at this time, 1.4, 1.6.2,
and trunk). When the sprint is complete, then the release candidate
process is started.

Release Candidates

Once a sprint is completed, release candidates for the various branches in
maintenance support mode are created. The first set of release candidates are
created directly from the branches themselves so as to incorporate all changes
that happened since the last set of releases (i.e. the last sprint).

Since we’re currently supporting the 1.4 and 1.6.2 branches of Asterisk, there
would create release candidates for both 1.4 and 1.6.2 created. Let’s say our
current versions of Asterisk are 1.4.30 and 1.6.2.5 which were released after
the previous sprint. We’re now completing another sprint and we’ve
gotten to the point of creating release candidates.

Our new set of release candidates would be created directly from the 1.4 and
1.6.2 branches respectively as:

• 1.4.31-rc1
• 1.6.2.6-rc1

The release candidates are then released to the public for additional testing
and to determine if there are any regressions not found by the Asterisk test
suite. If regressions are found, then the public can report those to the issue
tracker (https://issues.asterisk.org) where the bugs will be triaged, and if
deemed necessary, will be marked as a blocker for the release.

In the cases where regressions or blockers are found during a release candidate
cycle, then the issue is assigned to a developer. Once the issue has been
resolved, then new release candidates are created for the branches it affects.

Let’s say an issue was reported after 1.4.31-rc1 and 1.6.2.6-rc1 were released
which affects both versions. The issue would be triaged, marked as a blocker for
the pending 1.4.31 and 1.6.2.6 releases (which you could see on the Asterisk
roadmap), and assigned to a developer. Once the issue was resolved and closed,
it would be merged to the 1.4 and 1.6.2 branches.

The Asterisk release manager would then create a copy of the 1.4.31-rc1 and
1.6.2.6-rc1 tags and create tags 1.4.31-rc2 and 1.6.2.6-rc2 respectively. At
this point the tags would be identical. The release manager would then merge the
blocking change to the 1.4.31-rc2 and 1.6.2.6-rc2 tags, and would then update
the ChangeLog. New release candidates would then be created and released to the
public for additional testing.

If no further regressions or blockers are found in a release candidate, then the
final release candidate is copied to a new tag as a non-release candidates. Per
our example version, 1.4.31-rc2 would then be copied to 1.4.31 with no
additional changes, and then released.

The following is a visual representation of this process:

Visual representation of the release process

Releases

Because time and commits continue to progress from the point of the first
release candidate, you will see something like the following in the ChangeLogs:

2010-05-03  Leif Madsen
   * Asterisk 1.4.31 Released

2010-04-29  Leif Madsen
   * Asterisk 1.4.31-rc2 Released

2010-04-29 10:31 +0000 [r260049]  David Vossel
   * (commit message for blocker fix)

2010-04-28 10:31 +0000 [r259858]  David Vossel
   * (commit message for blocker fix)

2010-04-05  Leif Madsen
   * Asterisk 1.4.31-rc1 Released

Continue Reading »

• Information
• Comments Off