[asterisk-dev] Proposal to bring pjproject back into the fold

[George Joseph]

On Tue, Jan 19, 2016 at 9:34 PM, George Joseph <george.joseph at fairview5.com>
wrote:

>
>
> On Tue, Jan 19, 2016 at 7:52 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
>
>> OK, I'm going to take a deep breath here...
>>
>> The distributions policies against embedding libraries and statically
>> linking code isn't some arbitrary policy.  It's a hard-earned best practice
>> that's been proven over and over.
>>
>> I get that it's "easier" to not work with others to solve problems and to
>> basically do a soft-fork of the pjproject code and embed it into Asterisk
>> and get it all set up "just so".
>>
>> This is however, IMNHSO, short-sighted, anti-social behavior.  Asterisk
>> used to be pretty bad in this regard but recently has been much much
>> better.  I really don't want to see the clock turned back.
>>
>> My recommendations:
>>
>> 1) Work with the pjproject upstream to convert problematic compile-time
>> options into runtime configurable options.  That way multiple consumers of
>> the library can get pjproject to work the way that they need it to without
>> recompiling it.
>>
>> 2) If #1 isn't feasible, work with the pjproject upstream to set defaults
>> for compile-time options that work better for Asterisk.
>>
>> 3) Add runtime instrumentation to pjproject so that Asterisk can
>> determine if pjproject is configured correctly for use with Asterisk at
>> runtime.
>>
>> 4) Work with the distro maintainers to get pjproject packaged with the
>> compilation options that work best with Asterisk.
>>
>> 5) Write up good docs on how to compile pjproject from source for use
>> with Asterisk for those folks that like to compile with source.  Do your
>> best to make sure that it's easily findable in Google searches, as well as
>> linked to in the appropriate places from the Asterisk documentation.
>>
>> --
>> Jeff Ollie
>>
>> ​Philosophically speaking, ​I agree with you 100%.  Unfortunately, when
> philosophy meets the real world, things often don't go as planned.  The
> reality is that the majority of people who use Asterisk don't care whether
> pjproject is statically or dynamically linked or whether it's bundled or
> not.  They just want it to work and when it doesn't they want a solution.
> They want "1 throat to choke", they don't care whether it's Asterisk's
> fault or pjproject's fault and they especially don't want to have to figure
> out which it is themselves.  A quick search in the RedHat Bugzilla shows
> that only 3 tickets were opened against Asterisk in the past 2 years by non
> RedHat employees so it's certainly not the packagers they're asking for
> help.  It's the Asterisk team that's on the hook.
>
> While your suggestions can and should be taken and can help in the long
> term, it's not enough.  In the end, it's about the people who produce the
> software trying to help the people who use it.  I sympathize with the
> plight of the packagers, and if the packagers were fielding the issues I'd
> sympathize even more, but that's not the case and I always have issues with
> black-and-white policies that leave no room for exceptions or the
> application of common sense.
>
>
>>
>> ​Oh, of course, none of this is to say packagers CAN'T build and
dynamically link Asterisk.  I'd even add ./configure options to ​make that
as easy as it is today.  I would suggest however, that the JIRA ticket
process require that a user be running the statically linked version to
open a ticket and that the support guidelines highlight that the team may
not be able to effectively provide support when Asterisk is installed via
some other means.


> --
>> _____________________________________________________________________
>> -- 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160119/5b3ab906/attachment.html>