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

[Olle E. Johansson]

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