[asterisk-dev] Memory leak since Asterisk 16.5.x / pjsip

George Joseph gjoseph at digium.com
Tue Sep 17 21:06:24 CDT 2019


On Mon, Sep 16, 2019 at 12:45 PM Corey Farrell <git at cfware.com> wrote:

> Updating pjproject does take less time/effort than maintaining a fork
> for the many years of an LTS release.  That reduced effort isn't just
> free time to developers, the time is instead spent working on
> enhancements and bug fixes.  Maintaining a fork would prevent users from
> getting important upstream bug fixes and would introduce risk of
> regressions caused by the fork itself.  So my vote is that pjsip version
> bumps should not be held back.  I'm also not in favor of creating
> separate releases for pjsip version bumps, this takes time that I feel
> can/should be spent on other tasks.
>
> One thing I think Asterisk can improve is to always make sure that any
> pjsip version bump is prominently mentioned in release notes, probably a
> note in the CHANGES and/or UPGRADE files.  This would let people who use
> bundled pjproject of potentially major changes.  It would also tell
> users of non-bundled pjproject that they should upgrade their own
> libraries as the older version is no longer tested.
>

I think we normally do that unless we missed one by accident.
I also do a blog post with a title like 'PJproject x.x qualified for use by
Asterisk"



>
> On 9/16/19 1:06 PM, Michael Maier wrote:
> > On 15.09.19 at 21:19 Joshua C. Colp wrote:
> >> On Sun, Sep 15, 2019, at 2:21 AM, Michael Maier wrote:
> >>> BTW: I'm not really happy with the fact, that an existing LTS / stable
> version gets a new pjsip version "on the fly". From my point of view, this
> should have been
> >>> done during a normal development cycle and not during a stable phase.
> >> Since support for bundled PJSIP we've actively tried to keep up to
> date, so that we don't end up managing a fork and backporting a lot of
> patches. This has worked well
> >> for us and we haven't seen any problems - in fact we've gained some
> stability at times.
> > Chance - there's always a first time :-)
> > BTW: I like the bundling of pjsip!
> >
> >> If this is a problem in PJSIP this would be the first time we've
> encountered a
> >> regression. If people feel that we should instead lock versions then
> this is certainly something we can discuss. What do others think?
> >  From a developers perspective, it's for sure better to do it as you do
> it like now. From a users / customers perspective, it's most probably the
> other way round. I don't
> > want to have any deep changes during a LTS version (that's exactly why
> I'm using LTS versions). The new pjsip release should have been put to a
> new asterisk release, too.
> > Asterisk 16.x was thoroughly tested and released on base of pjsip 4.8.
> Anybody who wants new pjsip 4.9 should consider using new Asterisk version,
> too.
> >
> > At least, I would expect a severe distinction by using a dedicated minor
> version (without any own asterisk changes) to detect more easily potential
> pjsip regressions.
> >
> >
> > Thanks
> > Michael
> >
>
> --
> _____________________________________________________________________
> -- 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



-- 
*George Joseph*
Digium - A Sangoma Company | Software Developer | Software Engineering
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct/fax: +1 256 428 6012
Check us out at: https://digium.com ยท https://sangoma.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190917/afb7e4eb/attachment.html>


More information about the asterisk-dev mailing list