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 <d...@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 <o...@edvina.net > <mailto:o...@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 <ule...@gmail.com > > <mailto: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 <mailto:ule...@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
-- _____________________________________________________________________ -- 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
