[asterisk-dev] Module Deprecation, Default Not Building, and Removal

Fri Oct 2 06:34:49 CDT 2020

I think you misunderstand me. I am not against deprecation and deletion. I just want us to find a way to
try to get through to a larger group of users when we do this. For the SIP channel case, I don’t think anyone has
missed it - it’s been far too long with two channels, which is confusing.

There are propably a list of modules I would remove quickly if I was under Josh’s hat.
/O
> On 2 Oct 2020, at 12:18, Dan Jenkins <dan at nimblea.pe> wrote:
> 
> Ultimately whats stopping package maintainers from releasing "asterisk-full" which still has all the deprecated modules enabled.... and "asterisk" which follows the defaults? Nothing.... Other packages get released in such a way so why not asterisk? I'm 100% not qualified to talk about it because I don't use them or make them. I just think 4 years of something hanging around after its been decided to be deprecated is foolish - deprecation = "this isnt needed any more", as was stated earlier - its not a case of pjsip coming to town and chan_sip getting thrown out immediately.... the decision to deprecate it took years (and years, and years, and years) - no need to wait a further 4 years.
> 
> 
> 
> On Fri, Oct 2, 2020 at 8:48 AM Olle E. Johansson <oej at edvina.net <mailto:oej at edvina.net>> wrote:
> Hi!
> I like adding product management and actually removing stuff that the company can’t keep maintaining - and don’t wan’t to.
> 
> Compared with years ago a lot of users never bother building asterisk any more and don’t interface with the project,
> they just run “apt-get install asterisk” and they are done. We are much more in the hands of package managers and really,
> really need to interface with them to get information out. Asterisk is a plumbing tool, much like nginx or apache. I don’t
> follow those projects, haven’t built apache httpd from source for over ten years and get my information from packaging.
> 
> I think this has to be considered as well. 
> 
> Thanks Josh for pushing this process.
> 
> /O
> 
> > On 2 Oct 2020, at 00:45, Seán C McCord <ulexus at gmail.com <mailto:ulexus at gmail.com>> wrote:
> > 
> > On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote:
> >> I think I personally hesitate to be so aggressive because long ago the
> >> project was that way. We would push to remove things faster and such,
> >> and the result was upset people and complaints. Years later I still had
> >> people coming up to me at AstriCon talking about that stuff and how it screwed
> >> them over.
> > 
> > I think this is a key point which we, as developers and integrators can easily overlook.  We're being pulled in two direction:  one, we must always keep up-to-date in our implementations, and two, we must be able to work with what the customers are willing to use.  Once things are deprecated, it is far easier to push the customer to do the right thing.  Removal makes this easier.  Thus, faster deprecation and removal is better for the integrator/developer/consultant.
> > 
> > But we do not represent more than the barest fraction of the Asterisk user base.  The greater portion is running production workloads with very low tolerance for either change or down-time, and are resultingly very conservative with their upgrades and loathe to spend great effort into managing those upgrades.
> > 
> > If we accelerate deprecation, we may end up making the problem _worse_ (as it used to be), where users would simply not upgrade at all, because it was too difficult to do so.
> > 
> > I agree that 4 years feels like an eternity to _me_, but to an operator working with very slim margins, it is not nearly so glacial.
> > 
> > ---
> > 
> > Seán C McCord
> > ulexus at gmail.com <mailto:ulexus at gmail.com>
> > PGP/GPG: https://cycoresys.com/scm.asc <https://cycoresys.com/scm.asc>
> > 
> > -- 
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com <http://www.api-digital.com/> --
> > 
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev <http://lists.digium.com/mailman/listinfo/asterisk-dev>
> 
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com <http://www.api-digital.com/> --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev <http://lists.digium.com/mailman/listinfo/asterisk-dev>-- 
> _____________________________________________________________________
> -- 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/20201002/d907aea8/attachment.html>