On Thu, May 18, 2023 at 12:39 PM <aster...@phreaknet.org> wrote: > 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? >
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
-- _____________________________________________________________________ -- 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