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

[Dan Jenkins]

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> 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> 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
> > PGP/GPG: https://cycoresys.com/scm.asc
> >
> > --
> > _____________________________________________________________________
> > -- 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
>
>
> --
> _____________________________________________________________________
> -- 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/930ad417/attachment-0001.html>