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