[asterisk-dev] Asterisk and distributions (Debian, Fedora, etc)

[Daniel Pocock]

Following up from the SIP stack discussion, I think it may be useful to
have a separate thread to get comments from people about the
relationship of Asterisk with distributions.

I give some Debian examples, but this is just as valid for any other
distribution.


Some of the issues that come to mind:

- release cycles/cut off dates (e.g. Debian was `frozen' a few months
ago, no new Asterisk packages will be allowed until the next `stable'
release in 2 years, although updated packages can be distributed in
backports)

- maintenance cycles (e.g. Debian releases need 3 years of security
updates, RHEL needs 7, which is a long time for VoIP)

- interaction with the packaging process (e.g. more people joining as
Debian maintainer, which is a stepping-stone to becoming a full Debian
Developer)

- interaction with the support process (e.g. using Debian's bug tracker)

- addressing all of the above issues for dependencies, e.g. if using
libsrtp or resiprocate, how to make sure that distributions are all
carrying the version required by Asterisk?

This last issue (dependencies) is sometimes perceived as a major pain in
itself - but if it is planned from the beginning and co-ordinated with
other projects, it can be managed and it can work favorably.

At the end of the day, distributions bring a lot of users, and if
everything is planned well, then users don't have to ask questions about
dependencies or how to install.  This saves valuable support time.

I've worked with companies that just do telecoms and they don't mind
having bespoke servers for their apps, nor do they object to paying
fees for a freelance developer to fine tune everything.  However, as
more and more IT managers want VoIP, they don't want to spend time
building anything from source, they want the convenience of installing
with apt-get or yum, just like they do with Apache or Postfix or Mysql.

Having some clarity about these relationships may give insights about
the priorities for the SIP stack question.