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

[Joshua C. Colp]

On Thu, Oct 1, 2020 at 1:15 PM Dan Jenkins <dan at nimblea.pe> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201001/bde9a27a/attachment.html>