[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 <jcolp at sangoma.com> wrote:

> On Thu, Oct 1, 2020 at 11:49 AM Seán C McCord <ulexus at gmail.com> 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 <ulexus at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20201001/d9ef18cf/attachment-0001.html>