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 <ule...@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 > ule...@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
