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

- On Nov 9, 2020, at 8:23 AM, Joshua C. Colp wrote: > Since this is the first real time formalizing this once all the things are in > place (process documented on wiki, deprecation list created from existing > state > of things) I'll likely send out an email to -users and also post on the

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

On Mon, Nov 9, 2020 at 8:24 AM Joshua C. Colp wrote: > Since this is the first real time formalizing this once all the things are > in place (process documented on wiki, deprecation list created from > existing state of things) I'll likely send out an email to -users and also > post on the

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

Makes sense to me! Sent from my iPhone > On Nov 9, 2020, at 8:24 AM, Joshua C. Colp wrote: > >  >> On Tue, Oct 13, 2020 at 7:55 AM Joshua C. Colp wrote: > >> Hey all, >> >> I just wanted to drop an email and say that this hasn't been dropped or >> anything. A 2 year option just isn't

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

On Tue, Oct 13, 2020 at 7:55 AM Joshua C. Colp wrote: > Hey all, > > I just wanted to drop an email and say that this hasn't been dropped or > anything. A 2 year option just isn't something I want to rush into without > thinking through all the ripples, which since we're approaching AstriDevCon

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

Hey all, I just wanted to drop an email and say that this hasn't been dropped or anything. A 2 year option just isn't something I want to rush into without thinking through all the ripples, which since we're approaching AstriDevCon and AstriCon is something that occurs here and there at the

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

On Tue, Oct 6, 2020 at 2:23 PM Joshua C. Colp wrote: > As a packager and someone who has been in the community and user world, > what's your opinion and thoughts on the 2 year strategy? > I'm fine with it... for faster-moving distributions (such as Fedora), users are used to following new

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

On 2020-10-06 2:22 PM, Joshua C. Colp wrote: On Fri, Oct 2, 2020 at 4:18 PM Jared Smith > wrote: On Fri, Oct 2, 2020 at 11:50 AM Dan Jenkins mailto:d...@nimblea.pe>> wrote: sorry, I thought I was agreeing with you :) we need to engage

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

On Fri, Oct 2, 2020 at 4:18 PM Jared Smith wrote: > On Fri, Oct 2, 2020 at 11:50 AM Dan Jenkins wrote: > >> sorry, I thought I was agreeing with you :) we need to engage package >> maintainers to potentially help ease the shift - if packages are a >> thing but as far as I'm concerned most

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

I was hoping you'd pipe in again Jared! Thank you! On Fri, 2 Oct 2020, 20:20 Jared Smith, wrote: > On Fri, Oct 2, 2020 at 11:50 AM Dan Jenkins wrote: > >> sorry, I thought I was agreeing with you :) we need to engage package >> maintainers to potentially help ease the shift - if packages are a

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

On Fri, Oct 2, 2020 at 11:50 AM Dan Jenkins wrote: > sorry, I thought I was agreeing with you :) we need to engage package > maintainers to potentially help ease the shift - if packages are a > thing but as far as I'm concerned most package managers have out of > date versions of Asterisk,

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

Hi Olle, sorry, I thought I was agreeing with you :) we need to engage package maintainers to potentially help ease the shift - if packages are a thing but as far as I'm concerned most package managers have out of date versions of Asterisk, or don't have things you want so you end up building

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

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.

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

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

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

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

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

- On Oct 1, 2020, at 6:45 PM, 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

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

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

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

On Thu, Oct 1, 2020 at 7:46 PM Joshua C. Colp wrote: > On Thu, Oct 1, 2020 at 7:01 PM Dan Jenkins wrote: > >> Completely agree with Sean on the "what's going to be deprecated" >> question months before a cut. And I like the laid out plan that would be >> involved for 2 year process of

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

On Thu, Oct 1, 2020 at 7:01 PM Dan Jenkins wrote: > Completely agree with Sean on the "what's going to be deprecated" question > months before a cut. And I like the laid out plan that would be involved > for 2 year process of deprecation,default enabled no and then remove. > I think as soon as

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

Completely agree with Sean on the "what's going to be deprecated" question months before a cut. And I like the laid out plan that would be involved for 2 year process of deprecation,default enabled no and then remove. On Thu, 1 Oct 2020, 22:42 BJ Weschke, wrote: > I don’t think anyone would

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

I don’t think anyone would have suggested beginning any process of removal of the chan_sip module when development of chan_pjsip first began. In fact, the discussion and decision of deprecation of chan_sip didn’t come about until AstriDevCon 2018 which occurred nearly 27 months after that July

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

On 10/1/2020 7:56 AM, Joshua C. Colp wrote: Around this time each year a discussion always spurs (be it on IRC or at AstriDevCon) about deprecating modules, and removing them. I always find myself asking "what is our real process for doing this?" in my head and end up trying to piece it

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

as per my experience with systems built on top of asterisk not just vanilla asterisk it took like 4 full years from starting implantation for pjsip starting at Mon, 04 Jul 2016 12: >Added PJSIP tables and started integrating itFirst round of changes to introduce PJSIP... wow... it will be a huge

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

I’d personally be OK with this. The more I think about this, two years is really long enough. With your approach below, someone would have an entire LTS release cycle to make any necessary integration changes that come as a result of a module that is removed. If someone complains about

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

On Thu, Oct 1, 2020 at 4:31 PM BJ Weschke wrote: > Four years, is indeed, really long. I do agree with this. As an example, I > work with another project where the work involves some integrations with > software that is in the head units of vehicles. Right now, they’re working > to certify and

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

Four years, is indeed, really long. I do agree with this. As an example, I work with another project where the work involves some integrations with software that is in the head units of vehicles. Right now, they’re working to certify and lock down code and functionality for the 2023 vehicle

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

On Thu, 2020-10-01 at 20:14 +0100, Dan Jenkins wrote: > I'd argue two years isn't exactly quick... Especially with warnings > on previous minor releases after decisions have been made. 2 years > is fair - 4 is just too long. But if everyone else feels like 4 is > fine then I'll stop my protest ;)

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

I'd argue two years isn't exactly quick... Especially with warnings on previous minor releases after decisions have been made. 2 years is fair - 4 is just too long. But if everyone else feels like 4 is fine then I'll stop my protest ;) On Thu, 1 Oct 2020, 20:09 Joshua C. Colp, wrote: > On Thu,

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

On Thu, Oct 1, 2020 at 3:56 PM Dan Jenkins wrote: > If there was an additional message attached to minor releases, does that > mean we can accelerate the steps? > > On the question of why I'm opposed to 4 years? 4 years is an eternity to > be in limbo - we've already seen this with chan_sip -

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

If there was an additional message attached to minor releases, does that mean we can accelerate the steps? On the question of why I'm opposed to 4 years? 4 years is an eternity to be in limbo - we've already seen this with chan_sip - even though its deprecated in 17, people still start using

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

On Thu, Oct 1, 2020 at 2:28 PM Corey Farrell wrote: > Yes, or "core, deprecated in future versions" in the minors. I don't have > strong feelings on the exact language just that we should indicate the long > term future of a module has been decided. > > Also sorry I accidentally didn't send my

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

- On Oct 1, 2020, at 7:56 AM, Joshua C. Colp wrote: > Greetings all, > Around this time each year a discussion always spurs (be it on IRC or at > AstriDevCon) about deprecating modules, and removing them. I always find > myself > asking "what is our real process for doing this?" in my head

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

Yes, or "core, deprecated in future versions" in the minors.  I don't have strong feelings on the exact language just that we should indicate the long term future of a module has been decided. Also sorry I accidentally didn't send my last reply to the list. On 10/1/20 1:20 PM, Joshua C. Colp

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

On Thu, Oct 1, 2020 at 2:18 PM Corey Farrell wrote: > Yes I'm suggesting documenting that it is deprecated in minor releases. > Ending support in a minor seems bad unless support already doesn't exist. > Could we add AST_MODULE_SUPPORT_CORE_DEPRECATED and > AST_MODULE_SUPPORT_EXTENDED_DEPRECATED

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

On Thu, Oct 1, 2020 at 1:39 PM Dan Jenkins wrote: > Yup, totally get your point as we've already discussed it on IRC... it > just feels like 4 years is an eternity. Most people don't move to a new > version of an LTS immediately and usually have a plan on how to upgrade - > and its not even like

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

On Thu, Oct 1, 2020 at 1:51 PM Dan Jenkins wrote: > Fantastic idea Corey - that would get people knowing about things earlier > even if theyre not on a standard release. > > On Thu, Oct 1, 2020 at 5:46 PM Corey Farrell wrote: > >> Any reason we can't "documentation deprecate" things in minor

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

Fantastic idea Corey - that would get people knowing about things earlier even if theyre not on a standard release. On Thu, Oct 1, 2020 at 5:46 PM Corey Farrell wrote: > Any reason we can't "documentation deprecate" things in minor releases? > No runtime warnings and keep building by default

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

Any reason we can't "documentation deprecate" things in minor releases?  No runtime warnings and keep building by default but if we deprecate a module in master right now it seems like the next minor release of all active branches should document the status of the module.  The fact that a

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

Yup, totally get your point as we've already discussed it on IRC... it just feels like 4 years is an eternity. Most people don't move to a new version of an LTS immediately and usually have a plan on how to upgrade - and its not even like the LTS wouldnt include the module it just wouldnt be

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

On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins wrote: > Firstly, thank you Josh for trying to outline the process so that it's > something that can be followed and while I agree mostly with the steps... > the fact that its going to take 4 years for a module to be moved from > "deprecated" to being

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

Firstly, thank you Josh for trying to outline the process so that it's something that can be followed and while I agree mostly with the steps... the fact that its going to take 4 years for a module to be moved from "deprecated" to being removed just feels too long but understandable if we're

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

On Thu, Oct 1, 2020 at 11:49 AM Seán C McCord wrote: > On Thu Oct 1, 2020 at 10:34 AM EDT, Joshua C. Colp wrote: > > On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord wrote: > > > I, too, am in favour of this formalization. My only comment is that it > > > seems to me that default-enabled being

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

On Thu Oct 1, 2020 at 10:34 AM EDT, Joshua C. Colp wrote: > On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord wrote: > > I, too, am in favour of this formalization. My only comment is that it > > seems to me that default-enabled being turned off would seem to come before > > deprecation. I can see

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

I’m in favor of this approach as well.  On October 1, 2020 at 10:23:30 AM, Jared Smith (jaredsm...@jaredsmith.net) wrote: On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp wrote: Not really, and I think part of the problem is that this entire thing hasn't really been documented, communicated,

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

On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord wrote: > On Thu Oct 1, 2020 at 10:22 AM EDT, Jared Smith wrote: > > On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp > > OK, thanks for the clarification. Consider me in favor of the process as > > you outlined it, and also in favor of a more

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

On Thu Oct 1, 2020 at 10:22 AM EDT, Jared Smith wrote: > On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp > OK, thanks for the clarification. Consider me in favor of the process as > you outlined it, and also in favor of a more aggressive stance on > deprecation of modules that obviously aren't

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

On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp wrote: > Not really, and I think part of the problem is that this entire thing > hasn't really been documented, communicated, or been a strict part of the > release or development process. It's been more organic. Going forward it > would be

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

On Thu, Oct 1, 2020 at 11:01 AM Jared Smith wrote: > On Thu, Oct 1, 2020 at 9:20 AM Joshua C. Colp wrote: > >> 1. All the changes listed below initially occur in standard releases - in >> my opinion beginning the process to remove a module is a big thing and we >> should gradually introduce it,

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

On Thu, Oct 1, 2020 at 9:20 AM Joshua C. Colp wrote: > 1. All the changes listed below initially occur in standard releases - in > my opinion beginning the process to remove a module is a big thing and we > should gradually introduce it, gaining feedback from those who run standard > releases