[asterisk-dev] DAHDI and Asterisk

Joshua C. Colp jcolp at sangoma.com
Thu May 18 10:51:53 CDT 2023


On Thu, May 18, 2023 at 12:39 PM <asterisk at phreaknet.org> wrote:

> On 5/18/2023 11:09 AM, Joshua C. Colp wrote:
> > On Thu, May 18, 2023 at 12:05 PM <asterisk at phreaknet.org
> > <mailto:asterisk at phreaknet.org>> wrote:
> >
> >     Wanted to float a question here for the Asterisk core team, that has
> >     been discussed amongst several other Asterisk/DAHDI developers a bit.
> >
> >     As we all know, the DAHDI project has been neglected the past few
> >     years
> >     and it does not appear that there is any team at Sangoma that is
> >     actively working on it or cares about it. Sangoma has repeatedly
> >     failed
> >     to take responsibility for DAHDI and is not letting the community
> >     maintain it either, i.e. PRs are not being merged, build failures are
> >     not addressed. Numerous developers, myself included, have long been
> >     maintaining external patch sets[1] or forks[2] to address this.
> >
> >     At this point, it is unrealistic to expect the DAHDI project in its
> >     current form to ever really get back on track. Some distros I'm told
> >     have already abandoned Sangoma and now use the osmocom fork as their
> >     upstream for packages. Most people have been using these methods to
> >     build DAHDI, rather than using the Sangoma tarballs.
> >
> >     Merely maintaining patch sets or forks is not a long term
> >     solution. Many
> >     new Asterisk features require DAHDI changes, and thus require
> >     patches to
> >     be maintained for multiple projects. Even if the Asterisk side
> >     could be
> >     merged in fine, some changes may require or depend on a DAHDI
> >     change to
> >     work properly. Over time, patches begin to conflict with or step
> >     on each
> >     other. DAHDI does not live in a bubble and has impacts that ripple
> >     out
> >     to other things, like Asterisk.
> >
> >     Since DAHDI has no active maintainer currently, I wanted to float a
> >     couple ideas here to remedy the situation, in order of feasibility (I
> >     think):
> >
> >      1. Would it be possible for the DAHDI project to be moved to fall
> >     under
> >         the scope of the Asterisk project? e.g. similar to libpri. The
> >         Asterisk team would not need to actively do anything with it, but
> >         just merge changes into it as it does for libpri, for example
> >     (kind
> >         of like extended support). I think this would make the most sense
> >         because fundamentally, DAHDI is part of the Asterisk ecosystem.
> >         Asterisk has a dependence on DAHDI and so bringing that
> dependency
> >         in house makes sense since it eliminates friction. For
> >     example, this
> >         change[3] stalled solely because nobody is merging PRs into
> DAHDI.
> >         If the Asterisk team was able to merge DAHDI changes, problem
> >         solved, and then Asterisk changes aren't stalled because DAHDI is
> >         stalled.
> >
> >
> > No. This is not something that the Asterisk project or Asterisk team
> > will take on. We're trying to reduce the amount of responsibilities
> > (such as reducing the amount of infrastructure we maintain and manage)
> > we have to be able to focus on Asterisk itself, taking on new ones
> > particularly in areas we have no expertise in is not something we will
> > be doing.
>
> Understood.
>
> In this case, is there any possibility of accepting changes that have
> dependencies on DAHDI functionality that may not be present in the most
> recent Sangoma tarball, but exist in maintained versions of DAHDI? e.g.
> conditionally guarded if needed so that there aren't build issues,
> regardless of which version of DAHDI is used underneath. Such changes
> would be effective only when they actually exist and are supported by
> the underlying DAHDI version. Or is the Asterisk project restricted to
> using only the official Sangoma version, even though it's broken and
> stagnant?
>
> For example, this change[1] doesn't even have any build dependencies on
> DAHDI. It compiles and runs fine regardless. It will work if the
> underlying DAHDI change is present, and do nothing if it is not. Is that
> still a blocker on merging this? As Kevin said on the review, "Unless of
> course you're thinking the DAHDI changes may be not go in for a very
> long time, if at all and ppl will just manually apply patches
> themselves." People using this feature are going to do just that, so in
> practice there isn't a compatibility issue. Are there any circumstances
> under which patches like these may be merged?
>

This is uncharted territory so I would say yes they could be put up for
review and if reviewed merged, provided of course as you state it remains
backwards compatible.

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20230518/35721ffd/attachment.html>


More information about the asterisk-dev mailing list