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

[Michael L. Young]

- 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
> community forums so people are aware.

> Sound good to everyone?

Sounds like a good approach and reasonable. 

-- 
Michael L. Young 

(elguero) 
-- 
_
-- 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

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

[Jared Smith]

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 community forums so people are aware.
>

This sounds great to me.

-Jared
-- 
_
-- 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

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

[BJ Weschke]

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 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 moment. :D
> 
> I'm back, back again. Josh is back. Tell a friend.
> 
> After giving further thought to things and the opinions presented I think we 
> can safely try a 2 year approach since we have a notification mechanism in 
> the form of a standard release and notice in minor releases with the ability 
> to receive feedback from the community. This means the process would be:
> 
> 1. Minor releases receive change to indicate that module is to be deprecated 
> in a future major release
> 2. Module is marked deprecated and defaultenabled no in standard release 
> (19), which carries over to next LTS release (20)
> 3. Announcement and documentation for each includes notice of deprecated 
> modules
> 4. Standard release after this it is removed (21), which carries over to next 
> LTS release (22)
> 5. Announcement and documentation for each includes notice of removed modules
> 
> A wiki page would be kept to keep track of modules in process of being 
> removed, as well as history to show when things were actually removed.
> 
> 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 
> community forums so people are aware.
> 
> Sound good to everyone?
> 
> -- 
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> -- 
> _
> -- 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

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

[Joshua C. Colp]

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
> and AstriCon is something that occurs here and there at the moment. :D
>

I'm back, back again. Josh is back. Tell a friend.

After giving further thought to things and the opinions presented I think
we can safely try a 2 year approach since we have a notification mechanism
in the form of a standard release and notice in minor releases with the
ability to receive feedback from the community. This means the process
would be:

1. Minor releases receive change to indicate that module is to be
deprecated in a future major release
2. Module is marked deprecated and defaultenabled no in standard release
(19), which carries over to next LTS release (20)
3. Announcement and documentation for each includes notice of deprecated
modules
4. Standard release after this it is removed (21), which carries over to
next LTS release (22)
5. Announcement and documentation for each includes notice of removed
modules

A wiki page would be kept to keep track of modules in process of being
removed, as well as history to show when things were actually removed.

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 community forums so people are aware.

Sound good to everyone?

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Joshua C. Colp]

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 moment. :D

Cheers,

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Jared Smith]

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 releases closely, and fast rate of change with
regards to changes in those major releases.  For slower-moving
distributions (CentOS/RHEL/etc.), people tend to stick with LTS releases,
but understand that there are typically bigger (less granular) changes
between LTS releases than there are between regular releases.

-Jared
-- 
_
-- 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

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

[Sylvain Boily]

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
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 from source
anyway


I actively package Asterisk for Fedora and EPEL (CentOS/RHEL), and
I work hard to package the latest versions as they are released. 
I'm always open to additional input on how to make my packages
more relevant for consumers -- either by packaging additional
modules, or by having better sub-packages. For example, my
packages already have chan_sip and pjsip split off as separate
subpackages.


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?


Hello,

For us we have debian packages we maintain. We follow the latest stable 
version with a test suite and a bot make the package. So 2 years it's 
clearly not an issue. About chan_sip we completely removed it.


Sylvain
-- 
_
-- 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

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

[Joshua C. Colp]

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 package managers have out of
>> date versions of Asterisk, or don't have things you want so you end up
>> building from source anyway
>>
>
> I actively package Asterisk for Fedora and EPEL (CentOS/RHEL), and I work
> hard to package the latest versions as they are released.  I'm always open
> to additional input on how to make my packages more relevant for consumers
> -- either by packaging additional modules, or by having better
> sub-packages.  For example, my packages already have chan_sip and pjsip
> split off as separate subpackages.
>

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?

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Dan Jenkins]

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
>> 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 from source anyway
>>
>
> I actively package Asterisk for Fedora and EPEL (CentOS/RHEL), and I work
> hard to package the latest versions as they are released.  I'm always open
> to additional input on how to make my packages more relevant for consumers
> -- either by packaging additional modules, or by having better
> sub-packages.  For example, my packages already have chan_sip and pjsip
> split off as separate subpackages.
>
> -Jared
> --
> _
> -- 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

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

[Jared Smith]

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, or don't have things you want so you end up
> building from source anyway
>

I actively package Asterisk for Fedora and EPEL (CentOS/RHEL), and I work
hard to package the latest versions as they are released.  I'm always open
to additional input on how to make my packages more relevant for consumers
-- either by packaging additional modules, or by having better
sub-packages.  For example, my packages already have chan_sip and pjsip
split off as separate subpackages.

-Jared
-- 
_
-- 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

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

[Dan Jenkins]

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 from source anyway

Dan

On Fri, Oct 2, 2020 at 12:36 PM Olle E. Johansson  wrote:

> 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  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  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  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
>
> --
> _
> -- 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
>
>
> --
> 

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

[Olle E. Johansson]

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  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  > 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  > > 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 
> -- 
> _
> -- 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 

Re: [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  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  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
-- 
_
-- 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

Re: [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  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

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

[Michael L. Young]

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

Totally agree with Seán's assessment.

--
Michael Young

(elguero)

-- 
_
-- 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

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

[Seán C McCord]

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

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

[Joshua C. Colp]

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 deprecation,default enabled no and then
>> remove.
>>
>
> I think as soon as the LTS branch is cut from master and master
> transitions to being the development branch for the next standard release -
> it's fair game up until the point that the standard release is cut from
> master so essentially during that development cycle if someone thinks of
> another it can be discussed. As part of cutting the LTS branch a reminder
> can be sent and a discussion can be done, as well as before "feature
> freeze" of master for the next standard release. If someone thinks of one
> even outside of that window we can add it to the wiki page and those can
> form the start of the discussion.
>

Er I actually meant a reminder can be sent alongside the reminder about
upcoming feature freeze. That spaces things out a bit neater time wise so
we can have two planned discussions, with any unplanned ones in between.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Joshua C. Colp]

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 the LTS branch is cut from master and master transitions
to being the development branch for the next standard release - it's fair
game up until the point that the standard release is cut from master so
essentially during that development cycle if someone thinks of another it
can be discussed. As part of cutting the LTS branch a reminder can be sent
and a discussion can be done, as well as before "feature freeze" of master
for the next standard release. If someone thinks of one even outside of
that window we can add it to the wiki page and those can form the start of
the discussion.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Dan Jenkins]

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 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 2016
> milestone. (https://www.asterisk.org/astridevcon-2018-a-recap/)
>
>
> Sent from my iPhone
>
> On Oct 1, 2020, at 5:03 PM, משרד GIS מערכות תקשורת 
> wrote:
>
> 
> 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 blood bath, for start, you
> need asterisk 13.10 and chan_sip is not usable on 13.10. Stay tuned for
> next releases 
> till recently on,
> 11 May 2020 00:55:54 +0200 >Added a way to mass change the tech for
> extensions from chan_sip to PJSIP and back. It is available on
> Configuration/Extensions page
>
> and still fixing bugs  94 fixis  in four years when doing major changes 4
> years is needed minor stuff could go faster
>
> think of all the guys who are running asterisk the last 5 years and need a
> complete change you need time plan sometimes the latest os when you have
> just another integration crm which for now can work only with   the older
> os etc
>
> On Thu, Oct 1, 2020 at 10:55 PM Joshua C. Colp  wrote:
>
>> 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 lock down code and functionality for the 2023 vehicle model
>>> year which will hit dealer lots for the first time in just about two years
>>> from now. Once final certification occurs, in the vast majority of cases,
>>> nothing changes and the vehicles roll off the assembly line with the
>>> integration that was certified. If software that is involved in the
>>> manufacturing of vehicles can manage change risk within a two year window,
>>> it only seems reasonable that the Asterisk project should be able to do the
>>> same.
>>>
>>
>> From the development side we certainly can. The question is really - is
>> it fair to the Asterisk user base, will they they accept it, will there be
>> substantial backlash? The answer could be its fine. I don't really have a
>> concrete answer though at this moment and likely wouldn't until put into
>> action.
>>
>> For a 2 year strategy I think it would go as such:
>>
>> 1. Minor releases receive change to indicate that module is to be
>> deprecated in a future major release
>> 2. Module is marked deprecated and defaultenabled no in standard release
>> (19), which carries over to next LTS release (20)
>> 3. Announcement and documentation for each includes notice of deprecated
>> modules
>> 4. Standard release after this it is removed (21), which carries over to
>> next LTS release (22)
>> 5. Announcement and documentation for each includes notice of removed
>> modules
>>
>> A wiki page would still be kept to keep track of modules in process of
>> being removed.
>>
>> Note that I'm just putting this out there so people see in comparison to
>> the other one what the process would be like.
>>
>> --
>> Joshua C. Colp
>> Asterisk Technical Lead
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> --
>> _
>> -- 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
>
> --
> _
> -- 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

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

[BJ Weschke]

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 2016 
milestone. (https://www.asterisk.org/astridevcon-2018-a-recap/) 


Sent from my iPhone

> On Oct 1, 2020, at 5:03 PM, משרד GIS מערכות תקשורת  
> wrote:
> 
> 
> 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 blood bath, for start, you need 
> >asterisk 13.10 and chan_sip is not usable on 13.10. Stay tuned for next 
> >releases  
> till recently on, 
> 11 May 2020 00:55:54 +0200 >Added a way to mass change the tech for 
> extensions from chan_sip to PJSIP and back. It is available on 
> Configuration/Extensions page 
> 
> and still fixing bugs  94 fixis  in four years when doing major changes 4 
> years is needed minor stuff could go faster 
> 
> think of all the guys who are running asterisk the last 5 years and need a 
> complete change you need time plan sometimes the latest os when you have just 
> another integration crm which for now can work only with   the older os etc 
> 
>> On Thu, Oct 1, 2020 at 10:55 PM Joshua C. Colp  wrote:
>>> 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 lock down code and functionality for the 2023 vehicle model 
>>> year which will hit dealer lots for the first time in just about two years 
>>> from now. Once final certification occurs, in the vast majority of cases, 
>>> nothing changes and the vehicles roll off the assembly line with the 
>>> integration that was certified. If software that is involved in the 
>>> manufacturing of vehicles can manage change risk within a two year window, 
>>> it only seems reasonable that the Asterisk project should be able to do the 
>>> same.
>> 
>> From the development side we certainly can. The question is really - is it 
>> fair to the Asterisk user base, will they they accept it, will there be 
>> substantial backlash? The answer could be its fine. I don't really have a 
>> concrete answer though at this moment and likely wouldn't until put into 
>> action.
>> 
>> For a 2 year strategy I think it would go as such:
>> 
>> 1. Minor releases receive change to indicate that module is to be deprecated 
>> in a future major release
>> 2. Module is marked deprecated and defaultenabled no in standard release 
>> (19), which carries over to next LTS release (20)
>> 3. Announcement and documentation for each includes notice of deprecated 
>> modules
>> 4. Standard release after this it is removed (21), which carries over to 
>> next LTS release (22)
>> 5. Announcement and documentation for each includes notice of removed modules
>> 
>> A wiki page would still be kept to keep track of modules in process of being 
>> removed.
>> 
>> Note that I'm just putting this out there so people see in comparison to the 
>> other one what the process would be like.
>> 
>> -- 
>> Joshua C. Colp
>> Asterisk Technical Lead
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> -- 
>> _
>> -- 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
-- 
_
-- 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

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

[Sean Bright]

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 together based on some information 
here and there on the wiki plus past experience. I'd like to better 
document this and put something more concrete into place. To that end 
I'd like to propose the following:


Thanks for putting these thoughts on paper.

No matter what is ultimately decided, I would like to propose that we 
have some kind of scheduled x-number-of-months-before-release discussion 
where we can propose that a module be deprecated. It's good to have 
process around it, but I feel like we always end up discussing it _just 
after_ a new major version is released and it is too late to do anything 
about.


Kind regards,
Sean


--
_
-- 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

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

[משרד GIS מערכות תקשורת]

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 blood bath, for start, you need
asterisk 13.10 and chan_sip is not usable on 13.10. Stay tuned for next
releases 
till recently on,
11 May 2020 00:55:54 +0200 >Added a way to mass change the tech for
extensions from chan_sip to PJSIP and back. It is available on
Configuration/Extensions page

and still fixing bugs  94 fixis  in four years when doing major changes 4
years is needed minor stuff could go faster

think of all the guys who are running asterisk the last 5 years and need a
complete change you need time plan sometimes the latest os when you have
just another integration crm which for now can work only with   the older
os etc

On Thu, Oct 1, 2020 at 10:55 PM Joshua C. Colp  wrote:

> 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 lock down code and functionality for the 2023 vehicle model
>> year which will hit dealer lots for the first time in just about two years
>> from now. Once final certification occurs, in the vast majority of cases,
>> nothing changes and the vehicles roll off the assembly line with the
>> integration that was certified. If software that is involved in the
>> manufacturing of vehicles can manage change risk within a two year window,
>> it only seems reasonable that the Asterisk project should be able to do the
>> same.
>>
>
> From the development side we certainly can. The question is really - is it
> fair to the Asterisk user base, will they they accept it, will there be
> substantial backlash? The answer could be its fine. I don't really have a
> concrete answer though at this moment and likely wouldn't until put into
> action.
>
> For a 2 year strategy I think it would go as such:
>
> 1. Minor releases receive change to indicate that module is to be
> deprecated in a future major release
> 2. Module is marked deprecated and defaultenabled no in standard release
> (19), which carries over to next LTS release (20)
> 3. Announcement and documentation for each includes notice of deprecated
> modules
> 4. Standard release after this it is removed (21), which carries over to
> next LTS release (22)
> 5. Announcement and documentation for each includes notice of removed
> modules
>
> A wiki page would still be kept to keep track of modules in process of
> being removed.
>
> Note that I'm just putting this out there so people see in comparison to
> the other one what the process would be like.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- 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

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

[BJ Weschke]

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 defaultenabled no in 
the LTS release of which it is set that way, it seems to me that it is unlikely 
that same person would pay attention to any other documentation telling them 
that they had an integration issue to address even if they had two more years 
to do so. 

On October 1, 2020 at 3:55:19 PM, Joshua C. Colp (jc...@sangoma.com) wrote:


From the development side we certainly can. The question is really - is it fair 
to the Asterisk user base, will they they accept it, will there be substantial 
backlash? The answer could be its fine. I don't really have a concrete answer 
though at this moment and likely wouldn't until put into action.

For a 2 year strategy I think it would go as such:

1. Minor releases receive change to indicate that module is to be deprecated in 
a future major release
2. Module is marked deprecated and defaultenabled no in standard release (19), 
which carries over to next LTS release (20)
3. Announcement and documentation for each includes notice of deprecated modules
4. Standard release after this it is removed (21), which carries over to next 
LTS release (22)
5. Announcement and documentation for each includes notice of removed modules

A wiki page would still be kept to keep track of modules in process of being 
removed.

Note that I'm just putting this out there so people see in comparison to the 
other one what the process would be like.

--  
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
--  
_
-- 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

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

[Joshua C. Colp]

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 lock down code and functionality for the 2023 vehicle model
> year which will hit dealer lots for the first time in just about two years
> from now. Once final certification occurs, in the vast majority of cases,
> nothing changes and the vehicles roll off the assembly line with the
> integration that was certified. If software that is involved in the
> manufacturing of vehicles can manage change risk within a two year window,
> it only seems reasonable that the Asterisk project should be able to do the
> same.
>

>From the development side we certainly can. The question is really - is it
fair to the Asterisk user base, will they they accept it, will there be
substantial backlash? The answer could be its fine. I don't really have a
concrete answer though at this moment and likely wouldn't until put into
action.

For a 2 year strategy I think it would go as such:

1. Minor releases receive change to indicate that module is to be
deprecated in a future major release
2. Module is marked deprecated and defaultenabled no in standard release
(19), which carries over to next LTS release (20)
3. Announcement and documentation for each includes notice of deprecated
modules
4. Standard release after this it is removed (21), which carries over to
next LTS release (22)
5. Announcement and documentation for each includes notice of removed
modules

A wiki page would still be kept to keep track of modules in process of
being removed.

Note that I'm just putting this out there so people see in comparison to
the other one what the process would be like.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[BJ Weschke]

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 model year which will 
hit dealer lots for the first time in just about two years from now. Once final 
certification occurs, in the vast majority of cases, nothing changes and the 
vehicles roll off the assembly line with the integration that was certified. If 
software that is involved in the manufacturing of vehicles can manage change 
risk within a two year window, it only seems reasonable that the Asterisk 
project should be able to do the same. 

On October 1, 2020 at 3:15:12 PM, Dan Jenkins (d...@nimblea.pe) 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 ;) 

On Thu, 1 Oct 2020, 20:09 Joshua C. Colp,  wrote:
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 - even though its deprecated in 
17, people still start using Asterisk today and use chan_sip because they don't 
know any better and a crap load of documentation out on the internet uses it. 
If the modules are deprecated, they're deprecated for a reason - kill them as 
quickly as reasonably possible and be done with it - it'll help everyone in the 
community long term. If someone disagrees with say getting rid of chan_sip then 
they can continue to run 17/18 or whatever - or they can take the contents of 
chan_sip, and apply them as a patch themselves. I'm picking on chan_sip here 
because its the current thing that caused these conversations in the first 
place.

Okay, so you'd like to see it be faster because in your opinion its better for 
the user base long term to force the transition quickly.

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.

--  
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
--  
_
-- 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-- 
_
-- 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

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

[Fred Posner]

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 ;) 


I think it's a good starting point to go with 4... and then easier to
perhaps quicken that to 2 in the future. =)

-- 
Fred Posner
f...@qxork.com
https://qxork.com
Direct/SMS: +1 (336) 439-3733

Need Fred? Call Fred. 336-HEY-FRED
Matrix: @fred:matrix.lod.com

> 
> On Thu, 1 Oct 2020, 20:09 Joshua C. Colp,  wrote:
> > 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
> > > - even though its deprecated in 17, people still start using
> > > Asterisk today and use chan_sip because they don't know any
> > > better and a crap load of documentation out on the internet uses
> > > it. If the modules are deprecated, they're deprecated for a
> > > reason - kill them as quickly as reasonably possible and be done
> > > with it - it'll help everyone in the community long term. If
> > > someone disagrees with say getting rid of chan_sip then they can
> > > continue to run 17/18 or whatever - or they can take the
> > > contents of chan_sip, and apply them as a patch themselves. I'm
> > > picking on chan_sip here because its the current thing that
> > > caused these conversations in the first place.
> > > 
> > 
> > Okay, so you'd like to see it be faster because in your opinion
> > its better for the user base long term to force the transition
> > quickly.
> > 
> > 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.
> > 
> > -- 
> > Joshua C. Colp
> > Asterisk Technical Lead
> > Sangoma Technologies
> > Check us out at www.sangoma.com and www.asterisk.org


-- 
_
-- 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

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

[Dan Jenkins]

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, 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 - even though its
>> deprecated in 17, people still start using Asterisk today and use chan_sip
>> because they don't know any better and a crap load of documentation out on
>> the internet uses it. If the modules are deprecated, they're deprecated for
>> a reason - kill them as quickly as reasonably possible and be done with it
>> - it'll help everyone in the community long term. If someone disagrees with
>> say getting rid of chan_sip then they can continue to run 17/18 or whatever
>> - or they can take the contents of chan_sip, and apply them as a patch
>> themselves. I'm picking on chan_sip here because its the current thing that
>> caused these conversations in the first place.
>>
>
> Okay, so you'd like to see it be faster because in your opinion its better
> for the user base long term to force the transition quickly.
>
> 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.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- 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

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

[Joshua C. Colp]

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 - even though its
> deprecated in 17, people still start using Asterisk today and use chan_sip
> because they don't know any better and a crap load of documentation out on
> the internet uses it. If the modules are deprecated, they're deprecated for
> a reason - kill them as quickly as reasonably possible and be done with it
> - it'll help everyone in the community long term. If someone disagrees with
> say getting rid of chan_sip then they can continue to run 17/18 or whatever
> - or they can take the contents of chan_sip, and apply them as a patch
> themselves. I'm picking on chan_sip here because its the current thing that
> caused these conversations in the first place.
>

Okay, so you'd like to see it be faster because in your opinion its better
for the user base long term to force the transition quickly.

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.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Dan Jenkins]

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 Asterisk today and use chan_sip
because they don't know any better and a crap load of documentation out on
the internet uses it. If the modules are deprecated, they're deprecated for
a reason - kill them as quickly as reasonably possible and be done with it
- it'll help everyone in the community long term. If someone disagrees with
say getting rid of chan_sip then they can continue to run 17/18 or whatever
- or they can take the contents of chan_sip, and apply them as a patch
themselves. I'm picking on chan_sip here because its the current thing that
caused these conversations in the first place.

Dan

On Thu, Oct 1, 2020 at 7:07 PM Joshua C. Colp  wrote:

> 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 last reply to the list.
>>
>
> I think that's reasonable!
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- 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

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

[Joshua C. Colp]

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 last reply to the list.
>

I think that's reasonable!

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Michael L. Young]

- 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 and end up trying
> to piece it together based on some information here and there on the wiki plus
> past experience. I'd like to better document this and put something more
> concrete into place. To that end I'd like to propose the following:

> 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
> first.
> 2. The first step is marking a module as deprecated and occurs for 1 standard
> release and 1 LTS release
> 3. The second step is marking a module as defaultenabled no which means it 
> will
> not be built by default. This occurs for 1 standard release and 1 LTS release
> 4. The third step is removing the module
> 5. There will be a wiki page to keep track of all modules which are in the
> process of being removed
> 6. When a new LTS branch is created the master branch becomes eligible again 
> for
> changing the state of modules, a reminder can be done as part of cutting the
> LTS branch

> Thoughts?

The steps outlined seem very reasonable and appropriate. 

Great job on getting this hashed out and documented. 

-- 
Michael Young 

(elguero) 
-- 
_
-- 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

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

[Corey Farrell]

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 wrote:
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 to `enum
ast_module_support_level`?  Then a module would get one of those
support levels in a minor, AST_MODULE_SUPPORT_DEPRECATED in master.


We could, but just so I'm clear - it would be stated as "to be 
deprecated in future" essentially in minor releases and then marked as 
deprecated in master?


--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com  and 
www.asterisk.org 
-- 
_
-- 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

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

[Joshua C. Colp]

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 to `enum ast_module_support_level`?
> Then a module would get one of those support levels in a minor,
> AST_MODULE_SUPPORT_DEPRECATED in master.
>

We could, but just so I'm clear - it would be stated as "to be deprecated
in future" essentially in minor releases and then marked as deprecated in
master?

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Joshua C. Colp]

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 the LTS wouldnt include the module it just
> wouldnt be enabled by default and ultimately thats what the
> changelog/upgrade.txt is for isn't it?
>
> 4 years seems like a long time to get rid of something thats already been
> decided isnt being looked after any more.
>

Let me ask this too - why does 4 years seem long? What problem is being
solved by trying to reduce that time?

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Joshua C. Colp]

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 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
>> module will still be supported on 16.14.0 doesn't stop us from telling
>> users what will happen.
>>
>>
Are you referring to marking it as deprecated in both a minor release and
master? Or are you referring to marking it as deprecated in minor releases,
then default enabled to no in master?

There's no mechanism right now to state that a module will be deprecated,
just the current support level. We'd either need to add something else, add
a different support level, or mark it as deprecated and end the support for
it in a minor release.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Dan Jenkins]

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 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
> module will still be supported on 16.14.0 doesn't stop us from telling
> users what will happen.
> On 10/1/20 12:25 PM, Joshua C. Colp wrote:
>
> 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 removed just feels too long but understandable if
>> we're talking about "this module has GONE from the source code"
>>
>> I'm not really sure if my thought process here is tainted by the chan_sip
>> process that seems to have gone on for an eternity already.
>>
>> I personally don't see a problem with deprecating a module in non LTS and
>> removing it from being default enabled in the LTS - the code is still
>> there, and can still be enabled and packagers could still enable it. I
>> don't know what choices packagers make as to what gets built and what
>> doesn't as I don't use packages - each install f Asterisk has different
>> needs and so I always end up building from source. And then we could remove
>> it in the next standard release cutting the time by half.
>>
>> Would the above be ok if there was a "simple" way to say bring in
>> external modules at build time? IE movethe deprecated module to a separate
>> repo, and have the option to be able to bring it in dynamically during
>> build "at your own risk" - just like what happens with pjproject, codecs
>> etc
>>
>> Or is that not really achieving the goal because there would still need
>> to be some sort of maintenance for these deprecated modules.
>>
>
> That still incurs the maintenance burden in the first place. Even with an
> "at your own risk" perspective if you make it an easy ability to bring it
> in people will still have an expectation that it work, and when it doesn't
> then you need to deal with it in some way.
>
>
>>
>> I don't know... but essentially 4 years feels like forever and LTS and
>> Standard releases exist for a reason - I don't see why we need two LTS
>> releases before somethings removed.
>>
>
> The reason I opted for the way I did is that a portion of the user base
> don't run standard releases. They keep on LTS, so if you only do something
> in a standard release then they'll miss it. With my proposal standard
> release acts as an initial gauge of things before being released to the
> wider community. While I can understand the appeal of wanting to remove
> things as quickly as possible, it's not something I want to force as quick
> as possible upon the user base. It's a delicate balance to have so as to
> not drive people away, to give them time to transition and move, and to
> plan.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>
> --
> _
> -- 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

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

[Corey Farrell]

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 module will still be supported on 16.14.0 doesn't stop us from telling 
users what will happen.


On 10/1/20 12:25 PM, Joshua C. Colp wrote:
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 removed just feels too long
but understandable if we're talking about "this module has GONE
from the source code"

I'm not really sure if my thought process here is tainted by the
chan_sip process that seems to have gone on for an eternity already.

I personally don't see a problem with deprecating a module in non
LTS and removing it from being default enabled in the LTS - the
code is still there, and can still be enabled and packagers could
still enable it. I don't know what choices packagers make as to
what gets built and what doesn't as I don't use packages - each
install f Asterisk has different needs and so I always end up
building from source. And then we could remove it in the next
standard release cutting the time by half.

Would the above be ok if there was a "simple" way to say bring in
external modules at build time? IE movethe deprecated module to a
separate repo, and have the option to be able to bring it in
dynamically during build "at your own risk" - just like what
happens with pjproject, codecs etc

Or is that not really achieving the goal because there would still
need to be some sort of maintenance for these deprecated modules.


That still incurs the maintenance burden in the first place. Even with 
an "at your own risk" perspective if you make it an easy ability to 
bring it in people will still have an expectation that it work, and 
when it doesn't then you need to deal with it in some way.



I don't know... but essentially 4 years feels like forever and LTS
and Standard releases exist for a reason - I don't see why we need
two LTS releases before somethings removed.


The reason I opted for the way I did is that a portion of the user 
base don't run standard releases. They keep on LTS, so if you only do 
something in a standard release then they'll miss it. With my proposal 
standard release acts as an initial gauge of things before being 
released to the wider community. While I can understand the appeal of 
wanting to remove things as quickly as possible, it's not something I 
want to force as quick as possible upon the user base. It's a delicate 
balance to have so as to not drive people away, to give them time to 
transition and move, and to plan.


--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com  and 
www.asterisk.org 


-- 
_
-- 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

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

[Dan Jenkins]

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
enabled by default and ultimately thats what the changelog/upgrade.txt is
for isn't it?

4 years seems like a long time to get rid of something thats already been
decided isnt being looked after any more.

On Thu, Oct 1, 2020 at 5:27 PM Joshua C. Colp  wrote:

> 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 removed just feels too long but understandable if
>> we're talking about "this module has GONE from the source code"
>>
>> I'm not really sure if my thought process here is tainted by the chan_sip
>> process that seems to have gone on for an eternity already.
>>
>> I personally don't see a problem with deprecating a module in non LTS and
>> removing it from being default enabled in the LTS - the code is still
>> there, and can still be enabled and packagers could still enable it. I
>> don't know what choices packagers make as to what gets built and what
>> doesn't as I don't use packages - each install f Asterisk has different
>> needs and so I always end up building from source. And then we could remove
>> it in the next standard release cutting the time by half.
>>
>> Would the above be ok if there was a "simple" way to say bring in
>> external modules at build time? IE movethe deprecated module to a separate
>> repo, and have the option to be able to bring it in dynamically during
>> build "at your own risk" - just like what happens with pjproject, codecs
>> etc
>>
>> Or is that not really achieving the goal because there would still need
>> to be some sort of maintenance for these deprecated modules.
>>
>
> That still incurs the maintenance burden in the first place. Even with an
> "at your own risk" perspective if you make it an easy ability to bring it
> in people will still have an expectation that it work, and when it doesn't
> then you need to deal with it in some way.
>
>
>>
>> I don't know... but essentially 4 years feels like forever and LTS and
>> Standard releases exist for a reason - I don't see why we need two LTS
>> releases before somethings removed.
>>
>
> The reason I opted for the way I did is that a portion of the user base
> don't run standard releases. They keep on LTS, so if you only do something
> in a standard release then they'll miss it. With my proposal standard
> release acts as an initial gauge of things before being released to the
> wider community. While I can understand the appeal of wanting to remove
> things as quickly as possible, it's not something I want to force as quick
> as possible upon the user base. It's a delicate balance to have so as to
> not drive people away, to give them time to transition and move, and to
> plan.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- 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

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

[Joshua C. Colp]

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 removed just feels too long but understandable if
> we're talking about "this module has GONE from the source code"
>
> I'm not really sure if my thought process here is tainted by the chan_sip
> process that seems to have gone on for an eternity already.
>
> I personally don't see a problem with deprecating a module in non LTS and
> removing it from being default enabled in the LTS - the code is still
> there, and can still be enabled and packagers could still enable it. I
> don't know what choices packagers make as to what gets built and what
> doesn't as I don't use packages - each install f Asterisk has different
> needs and so I always end up building from source. And then we could remove
> it in the next standard release cutting the time by half.
>
> Would the above be ok if there was a "simple" way to say bring in external
> modules at build time? IE movethe deprecated module to a separate repo, and
> have the option to be able to bring it in dynamically during build "at your
> own risk" - just like what happens with pjproject, codecs etc
>
> Or is that not really achieving the goal because there would still need to
> be some sort of maintenance for these deprecated modules.
>

That still incurs the maintenance burden in the first place. Even with an
"at your own risk" perspective if you make it an easy ability to bring it
in people will still have an expectation that it work, and when it doesn't
then you need to deal with it in some way.


>
> I don't know... but essentially 4 years feels like forever and LTS and
> Standard releases exist for a reason - I don't see why we need two LTS
> releases before somethings removed.
>

The reason I opted for the way I did is that a portion of the user base
don't run standard releases. They keep on LTS, so if you only do something
in a standard release then they'll miss it. With my proposal standard
release acts as an initial gauge of things before being released to the
wider community. While I can understand the appeal of wanting to remove
things as quickly as possible, it's not something I want to force as quick
as possible upon the user base. It's a delicate balance to have so as to
not drive people away, to give them time to transition and move, and to
plan.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Dan Jenkins]

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 talking about "this module has GONE from the source code"

I'm not really sure if my thought process here is tainted by the chan_sip
process that seems to have gone on for an eternity already.

I personally don't see a problem with deprecating a module in non LTS and
removing it from being default enabled in the LTS - the code is still
there, and can still be enabled and packagers could still enable it. I
don't know what choices packagers make as to what gets built and what
doesn't as I don't use packages - each install f Asterisk has different
needs and so I always end up building from source. And then we could remove
it in the next standard release cutting the time by half.

Would the above be ok if there was a "simple" way to say bring in external
modules at build time? IE movethe deprecated module to a separate repo, and
have the option to be able to bring it in dynamically during build "at your
own risk" - just like what happens with pjproject, codecs etc

Or is that not really achieving the goal because there would still need to
be some sort of maintenance for these deprecated modules.

I don't know... but essentially 4 years feels like forever and LTS and
Standard releases exist for a reason - I don't see why we need two LTS
releases before somethings removed.

On Thu, Oct 1, 2020 at 3:56 PM Joshua C. Colp  wrote:

> 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 turned off would seem to come
>> before
>> > > deprecation.  I can see the other side, though.
>> > >
>> >
>> > I pondered that once, but I think to the user base it would be too much
>> > of a drastic change. I think of it as a gradual nudging essentially.
>> > Changing to deprecated and notes being informational for planning,
>> default
>> > enabled being an interrupt to actually do something. Of course there
>> will still
>> > be individuals who don't see this stuff - but one can only do so much.
>>
>> I can understand that, but I also look at it from the packager's
>> perspective:  for the most generic appeal, I would generally want to enable
>> everything which wasn't either experimental or deprecated.  The
>> default-enabled status would not be of interest.  If packagers followed
>> that way of thinking, you would, in fact, be _causing_ a more abrupt
>> change.  By switching this around, you would not impact lazy users who do
>> not compile their own Asterisk at first, but would gain the attention (one
>> hopes) of those who are ever so slightly more advanced.  This bifurcates
>> the impact to affect the more advanced users first, rather than the other
>> way around.
>>
>
> Jared is a packager and would have insight into this. I don't have
> experience in that regard. My experience is purely from the user base we
> directly support, which mostly build from source themselves. I can say from
> that perspective that starting with default enabled to no would be a huge
> impact and there would be backlash if no prior notice was given.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- 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

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

[Joshua C. Colp]

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 turned off would seem to come
> before
> > > deprecation.  I can see the other side, though.
> > >
> >
> > I pondered that once, but I think to the user base it would be too much
> > of a drastic change. I think of it as a gradual nudging essentially.
> > Changing to deprecated and notes being informational for planning,
> default
> > enabled being an interrupt to actually do something. Of course there
> will still
> > be individuals who don't see this stuff - but one can only do so much.
>
> I can understand that, but I also look at it from the packager's
> perspective:  for the most generic appeal, I would generally want to enable
> everything which wasn't either experimental or deprecated.  The
> default-enabled status would not be of interest.  If packagers followed
> that way of thinking, you would, in fact, be _causing_ a more abrupt
> change.  By switching this around, you would not impact lazy users who do
> not compile their own Asterisk at first, but would gain the attention (one
> hopes) of those who are ever so slightly more advanced.  This bifurcates
> the impact to affect the more advanced users first, rather than the other
> way around.
>

Jared is a packager and would have insight into this. I don't have
experience in that regard. My experience is purely from the user base we
directly support, which mostly build from source themselves. I can say from
that perspective that starting with default enabled to no would be a huge
impact and there would be backlash if no prior notice was given.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Seán C McCord]

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 the other side, though.
> >
>
> I pondered that once, but I think to the user base it would be too much
> of a drastic change. I think of it as a gradual nudging essentially.
> Changing to deprecated and notes being informational for planning, default
> enabled being an interrupt to actually do something. Of course there will 
> still
> be individuals who don't see this stuff - but one can only do so much.

I can understand that, but I also look at it from the packager's perspective:  
for the most generic appeal, I would generally want to enable everything which 
wasn't either experimental or deprecated.  The default-enabled status would not 
be of interest.  If packagers followed that way of thinking, you would, in 
fact, be _causing_ a more abrupt change.  By switching this around, you would 
not impact lazy users who do not compile their own Asterisk at first, but would 
gain the attention (one hopes) of those who are ever so slightly more advanced. 
 This bifurcates the impact to affect the more advanced users first, rather 
than the other way around.


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

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

[BJ Weschke]

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, or been a strict part of the release or 
development process. It's been more organic. Going forward it would be 
explicitly part of the steps when cutting the new branch, for example, and part 
of the announcement.

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 being heavily used/maintained.  

-Jared
--  
_
-- 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

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

[Joshua C. Colp]

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 aggressive stance on
> > deprecation of modules that obviously aren't being heavily
> > used/maintained.
>
> 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 the other side, though.
>

I pondered that once, but I think to the user base it would be too much of
a drastic change. I think of it as a gradual nudging essentially. Changing
to deprecated and notes being informational for planning, default enabled
being an interrupt to actually do something. Of course there will still be
individuals who don't see this stuff - but one can only do so much.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Seán C McCord]

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 being heavily
> used/maintained.

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 the other side, though.

---

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

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

[Jared Smith]

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 explicitly part of the steps when cutting the new branch, for
> example, and part of the announcement.
>

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 being heavily used/maintained.

-Jared
-- 
_
-- 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

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

[Joshua C. Colp]

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, gaining feedback from those who run standard
>> releases first.
>> 2. The first step is marking a module as deprecated and occurs for 1
>> standard release and 1 LTS release
>> 3. The second step is marking a module as defaultenabled no which means
>> it will not be built by default. This occurs for 1 standard release and 1
>> LTS release
>> 4. The third step is removing the module
>> 5. There will be a wiki page to keep track of all modules which are in
>> the process of being removed
>> 6. When a new LTS branch is created the master branch becomes eligible
>> again for changing the state of modules, a reminder can be done as part of
>> cutting the LTS branch
>>
>> Thoughts?
>>
>
> I'm fine with the process you propose -- it's roughly the same process
> we've discussed each year at AstriDevCon for the past several years.  But
> in addition to the process, I think we actually need follow-through as
> well.  I feel (for better or for worse) that most Asterisk developers have
> been in agreement on the process for years now, but little actual work to
> deprecate modules (other the obvious chan_sip and "deprecate the dialplan"
> discussions) has been done.
>
> Other than the chan_sip changes, have any other modules been marked as
> deprecated, or set to "defaultenabled no"?  Maybe there is a bunch and I've
> just missed them...
>

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 explicitly part of the steps when cutting the new branch, for
example, and part of the announcement.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[Jared Smith]

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 first.
> 2. The first step is marking a module as deprecated and occurs for 1
> standard release and 1 LTS release
> 3. The second step is marking a module as defaultenabled no which means it
> will not be built by default. This occurs for 1 standard release and 1 LTS
> release
> 4. The third step is removing the module
> 5. There will be a wiki page to keep track of all modules which are in the
> process of being removed
> 6. When a new LTS branch is created the master branch becomes eligible
> again for changing the state of modules, a reminder can be done as part of
> cutting the LTS branch
>
> Thoughts?
>

I'm fine with the process you propose -- it's roughly the same process
we've discussed each year at AstriDevCon for the past several years.  But
in addition to the process, I think we actually need follow-through as
well.  I feel (for better or for worse) that most Asterisk developers have
been in agreement on the process for years now, but little actual work to
deprecate modules (other the obvious chan_sip and "deprecate the dialplan"
discussions) has been done.

Other than the chan_sip changes, have any other modules been marked as
deprecated, or set to "defaultenabled no"?  Maybe there is a bunch and I've
just missed them...

-Jared
-- 
_
-- 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