[asterisk-dev] About asterisk development plans

[Olle E. Johansson]

17 mar 2009 kl. 20.32 skrev Jon Bonilla (Manwe):

> Hi all
>
> First of all I should begin thanking all of you for your efforts.  
> This mail is
> not intended to begin a flame or something like that. Or maybe it  
> does but in a
> polite way.
>
> I just have read the new released Asterisk 1.4.24 Changelog. IMHO it  
> is
> incredible and surpraising such a Changelog in a 24th release of a  
> feature
> frozen branch.
>
> IMHO again, Asterisk 1.4 branch after more than 2 years of stability  
> and bug
> squashing development is not ready for many production enviroments.  
> Many
> features considered *basic* such as transfers, pickup and a working  
> CDR are
> broken. New releases seem to break at least as many things as they  
> solve.
>
> Many people I know are going back from lastest 1.4.2X releases to  
> 1.4.14-1.4.17
> because it seems that newer releases are more inestable than older  
> ones. After
> two years of work in a frozen branch I think it should be rock-solid  
> and
> changelogs should be minimal but they are not.
It is indeed a big problem that I meet all the time. Do you have any  
proposal on
how to change it?

Digium pays for almost all of the development, especially the bug  
fixing part, today.
They have a large team that spends a large part of their time in the  
bug tracker,
which you see in the Changes file. They do what they can and are very  
skilled.
We have beta-releases and rc-releases of new 1.4 releases for feedback  
from
the community. And we still have the issues you describe.

Is Asterisk simply too complex to get stability on all the supported  
platforms,
with all the supported protocols and drivers for various devices? Is it
possible to fix it?

It may be an issue of priorities too. Maybe we can implement some  
system to
help Leif Madsen prioritize among the bugs. Bugs that I feel are  
critical, like
the early media audio from PRI links, may be unimportant for you. For  
me it's
a showstopper. You might have something else. How should this be
handled?

Is there any way we can get the community to contribute a bit more?
I can't spend any time on bug fixing in the SIP channel at this time,  
since
there's simply no company or group of companies that funds this work.
I feel really bad about it, as there are a large amount of SIP bugs in  
the
bug tracker that really needs attention. Leif keeps asking for help, I  
keep
promising but have a hard time fulfilling it. At the end of the month,  
one needs
a salary. It's as simple as that.
>
> Many developers are working on the new 1.6 branch now. The new  
> branch has now
> a new release policy, with new feature adoption between large  
> version changes.
> I am sure this policy change came after a deep discussion about the
> convenience of such change but I am asking myself if that decision  
> was the
> right one. Every developer likes adding new "sexy cool features" to  
> the code
> but vg: How more important is to add a calendar API to Asterisk  
> rather than
> rewriting a *working* CDR? Will be posible to stabilize the 1.6  
> branch adding
> new features while it has not been possible to do so with the 1.4  
> branch after
> more than 2 years?
I personally think that the new release policy makes 1.6 impossible to  
use
in any production environment. I've said that many times, so it's not  
any news
for any one. I'm maintaining a private version of Asterisk 1.4 for my  
carrier
customers with backports of smaller changes in the 1.6 branch (all  
available
in my svn directory). The cost of evaluating a new version is high and  
1.6
release policy is not acceptable, since the core keep changing too fast.

The plan I've outlined earlier on this list, which got support from  
Russell,
was at some point to fork the 1.6 code and create a kind-of "Centos"
distribution with long-term support for this group. So far, no  
customer has
shown interest and with the state of the SIP channel in the 1.6 tree
(Digium doesn't like me saying that, but anyway...) I don't see
it coming soon. For such a branch to succeed, we will need a test
team that works with it and a developer team that focuses on it,
which requires external funding. Large scale carrier installations is  
not
within Digium's commercial focus today.

>
> Once again I should apoligize if someone misunderstands my words. I  
> just am
> willing to know what the goal of this project is. If it's goal is to  
> be a
> ready-for-production-environment PBX, I think it should focus on  
> stability much
> more.

This is a very important discussion that I'm glad that you bring up.  
It is indeed
very boring to fix bugs and test, test, test. The Digium team surely  
focuses a
lot on bug fixing and testing, much more so today than a few years  
ago. I think
we all agree on the goal. The big question is how to get there. Will  
more resources
help? Is there a methodology problem in the testing done? Is the world  
too
complex for Asterisk to live in? Help us.

We do need the community to step in and work on this alongside with  
Digium.
We need the community to take a more active role in managing Asterisk  
and not
leave it to Digium. Digium is doing more than their share. Asterisk  
needs the
community taking responsibility.

Step in!

/O

PS: For CDR's, there's a very good developer available, Steve Murphy,
who has asked for support for his work on the asterisk-biz mailing list.
If you want CDR to be worked on, contact him and make an arrangement.
The more sponsors that steps in, the cheaper it will get for everyone.