On 5/18/2023 11:09 AM, Joshua C. Colp wrote:
On Thu, May 18, 2023 at 12:05 PM <aster...@phreaknet.org
<mailto:aster...@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?
I am aware that such an email has been sent to parties inside of
Sangoma, and have given my opinion to them on the situation. I'm not
in a position to provide any further insight into that or decide for
them. Any decisions has to come from them.
If there really is a plan inside Sangoma to deal with this, that is
great and I certainly welcome hearing from them. But based on what
(hasn't) happened so far, I doubt any decisions will be made. Thanks for
your insight though.
[1] https://gerrit.asterisk.org/c/asterisk/+/17948
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
