<div dir="ltr">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".... <div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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....</div><div><br></div><div>Or is that not really achieving the goal because there would still need to be some sort of maintenance for these deprecated modules.....</div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 3:56 PM Joshua C. Colp <<a href="mailto:jcolp@sangoma.com">jcolp@sangoma.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Oct 1, 2020 at 11:49 AM Seán C McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu Oct 1, 2020 at 10:34 AM EDT, Joshua C. Colp wrote:<br>
> On Thu, Oct 1, 2020 at 11:32 AM Seán C McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>> wrote:<br>
> > I, too, am in favour of this formalization.  My only comment is that it<br>
> > seems to me that default-enabled being turned off would seem to come before<br>
> > deprecation.  I can see the other side, though.<br>
> ><br>
><br>
> I pondered that once, but I think to the user base it would be too much<br>
> of a drastic change. I think of it as a gradual nudging essentially.<br>
> Changing to deprecated and notes being informational for planning, default<br>
> enabled being an interrupt to actually do something. Of course there will still<br>
> be individuals who don't see this stuff - but one can only do so much.<br>
<br>
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.<br></blockquote></div><div><br></div>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.<br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div>