<div dir="ltr">I just wanted to know if it was an out-of-hand distaste or some more fundamental complication.  Not enough timeshare is a perfectly acceptable reason.  It's not like I have a whole bunch of free time to do release engineering, after all, either!<div><br></div><div>Thanks</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 23, 2017 at 9:59 AM Matt Fredrickson <<a href="mailto:creslin@digium.com">creslin@digium.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 18, 2017 at 8:03 AM, Seán C. McCord <<a href="mailto:ulexus@gmail.com" target="_blank">ulexus@gmail.com</a>> wrote:<br>
> Matt,<br>
><br>
>  would you care to expound on your reasons against 14.6 -> LTS?  I don't<br>
> have all the data, so I certainly don't discount the possibility that there<br>
> are compelling "reasons," but those that you gave, such as they are, are too<br>
> vague to form an argument against.<br>
<br>
Hey Sean,<br>
<br>
I think that Sidney hit the nail on the head.  Trying to go through<br>
that kind of change right now would be challenging, a lot of it due to<br>
preparations in getting 15 tested, released, and out there, Astricon<br>
preparations, and more importantly, AstriDevCon preparations and other<br>
things of that nature that are happening right now.  You'd never<br>
believe how much time it takes to make all of that come together<br>
(never mind all of the day to day demands).<br>
<br>
It's a non insignificant amount of work from just a project policy<br>
perspective to make a change like you and Dan are proposing.  I'm not<br>
completely opposed to the proposal, but my fallback preference is to<br>
just keep current policy and wait until 16 is released to cut a new<br>
LTS.  Or at the very least discuss this more after 15 is released.<br>
<br>
Matthew Fredrickson<br>
<br>
><br>
><br>
> On Fri, Aug 18, 2017 at 5:07 AM Dan Jenkins <<a href="mailto:dan.jenkins88@gmail.com" target="_blank">dan.jenkins88@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Thu, Aug 17, 2017 at 11:11 PM, Matt Fredrickson <<a href="mailto:creslin@digium.com" target="_blank">creslin@digium.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Tue, Aug 15, 2017 at 1:15 PM, Dan Jenkins <<a href="mailto:dan.jenkins88@gmail.com" target="_blank">dan.jenkins88@gmail.com</a>><br>
>>> wrote:<br>
>>> ><br>
>>> ><br>
>>> > On Wed, Aug 2, 2017 at 10:57 PM, Matt Fredrickson <<a href="mailto:creslin@digium.com" target="_blank">creslin@digium.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> It is with great pleasure I wish to inform you of the first beta<br>
>>> >> release of the new Asterisk 15 branch. It's a very exciting time to be<br>
>>> >> a user of Asterisk! Asterisk 15 is arguably the biggest release of<br>
>>> >> Asterisk that has happened in the last 10 or so years. There has been<br>
>>> >> a lot of work done in the Asterisk core to better support newer<br>
>>> >> multi-stream video and WebRTC related technologies.  For those who are<br>
>>> >> interested, much of this will be covered in blog posts at<br>
>>> >> <a href="http://blogs.asterisk.org/" rel="noreferrer" target="_blank">http://blogs.asterisk.org/</a> over the next month or two.<br>
>>> >><br>
>>> >> Typically, when a new major branch of Asterisk is created (13, 14,<br>
>>> >> 15...), there are a few months of testing on the new branch that<br>
>>> >> occurs prior to release in order to find regressions and other issues<br>
>>> >> that may cause a first official release from the branch to be dead on<br>
>>> >> arrival for a significant number of users. With today's release of<br>
>>> >> 15.0.0-beta1, this process has begun. Please feel free to start<br>
>>> >> testing this version of Asterisk in as many adverse environments as<br>
>>> >> possible. Any bugs should be reported on the Asterisk issue tracker at<br>
>>> >> <a href="https://issues.asterisk.org/" rel="noreferrer" target="_blank">https://issues.asterisk.org/</a><br>
>>> >><br>
>>> >> As a side note, due to many of the core changes in the 15 branch that<br>
>>> >> have been made since Asterisk 14 was released, it has been decided<br>
>>> >> that Asterisk 15 will not be an LTS release. For those of you who are<br>
>>> >> not familiar with the differences between LTS versus standard<br>
>>> >> releases, you can find more information here [1].<br>
>>> >><br>
>>> >> Thanks to all the many Asterisk community members for providing so<br>
>>> >> much help and support to make Asterisk the great open source project<br>
>>> >> that it is.<br>
>>> >><br>
>>> >> P.S. Binary codecs and other modules distributed by Digium are not<br>
>>> >> immediately available for 15.0.0-beta1, but should be shortly.<br>
>>> >><br>
>>> >> Best wishes to all, and happy testing!<br>
>>> >><br>
>>> >> [1] <a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions</a><br>
>>> >><br>
>>> >> --<br>
>>> >> Matthew Fredrickson<br>
>>> >> Digium, Inc. | Engineering Manager<br>
>>> >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
>>> >><br>
>>> >> --<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><br>
>>> ><br>
>>> ><br>
>>> > After talking to Sean McCord about this, I realised you didn't say<br>
>>> > anything<br>
>>> > about releasing a new LTS; which you don't _have_ to do but personally<br>
>>> > I<br>
>>> > have clients who are looking to use new features in 14 under an LTS and<br>
>>> > that's what we were expecting - I'm sure there are businesses out there<br>
>>> > that<br>
>>> > still want an LTS to move to.<br>
>>> ><br>
>>> > The reason we are all expecting an LTS is because of this line in the<br>
>>> > wiki<br>
>>> > on the page you linked to "New releases of Asterisk will be made<br>
>>> > roughly<br>
>>> > once a year, alternating between standard and LTS releases."<br>
>>> > (<a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions</a>)<br>
>>><br>
>>> First off, thanks for expressing your sincere concerns with not making<br>
>>> 15 an LTS release :-)<br>
>>><br>
>>> I know that this change will cause some difficulty for certain members<br>
>>> of the community, particularly with those that were expecting 14<br>
>>> related features to be in an LTS sometime soon.  This discussion is<br>
>>> something that has been on my mind for a while and the decision was<br>
>>> not made lightly.<br>
>>><br>
>>> The major reason that it was decided to break convention and to not<br>
>>> make 15 an LTS is that there were some fairly considerable core<br>
>>> changes to Asterisk necessary to make the multi-stream work come<br>
>>> together to build an MVP video SFU out of Asterisk, which was our<br>
>>> goal.  Bearing that in mind, we did not feel comfortable building an<br>
>>> LTS release fresh off of those considerable core changes.<br>
>>><br>
>>> We also anticipate a number of other considerable changes going into<br>
>>> the 15 branch as people start to play with the new SFU support.  Since<br>
>>> our proof of concept client is so bare bones (doesn't use Asterisk ARI<br>
>>> APIs yet) we expect there to be many of ARI API enrichments that are<br>
>>> likely to happen as people start to play with the new SFU support in<br>
>>> app_confbridge.  There are also potentially more fundamental changes<br>
>>> that could break clients if some of our initial behavioral assumptions<br>
>>> are incorrect, such as how app_confbridge reuses negotiated streams on<br>
>>> peerconnections or how new streams are negotiated and in what order.<br>
>>><br>
>>> I know this places great difficulty on those who are using 14 features<br>
>>> counting on 15 being an LTS, but to be honest, I don't think that you<br>
>>> would want to use those features in a 15 LTS if you were concerned<br>
>>> about potential stability changes.  While we earnestly hope that 15<br>
>>> will continue 13 and 14's trend of being some of most solid stable<br>
>>> releases that have been cut, in an abundance of caution we decided to<br>
>>> break convention and make it non-LTS.<br>
>>><br>
>>> > I'd like to propose that we make 14.6 (or later) the LTS in a similar<br>
>>> > fashion to how other communities are now promoting versions to LTS mid<br>
>>> > cycle<br>
>>> > (<a href="https://github.com/nodejs/LTS" rel="noreferrer" target="_blank">https://github.com/nodejs/LTS</a>). That way you get to release all the<br>
>>> > exciting things that are in 15 but as a community we get LTS support on<br>
>>> > everything thats now in 14 - as we know, some businesses will not move<br>
>>> > to a<br>
>>> > non LTS and I think it would be a real shame to not get particular<br>
>>> > organisations moved over to using some of the great things that have<br>
>>> > been<br>
>>> > added in 14.<br>
>>> ><br>
>>> > What are everyone's thoughts?<br>
>>><br>
>>> So from a project policy perspective, and due to the many other<br>
>>> burdens we have right now, I don't feel comfortable making this change<br>
>>> at this time.  I'm not saying it's never going to happen, just that I<br>
>>> can't imagine going forward with everything else going on right now.<br>
>>><br>
>>> From a compromise position perspective, if your customers really would<br>
>>> like to get on an LTS with particular features that they're enjoying<br>
>>> in 14 (such as newer ARI changes, etc), there is a potential pathway<br>
>>> forward that might allow this sooner rather than later.  As long as<br>
>>> the changes they want are not of the nature to destabilize the<br>
>>> codebase (such as the DNS changes and a few others) or breaking API<br>
>>> changes, they can find a software developer to backport them into the<br>
>>> 13 branch.  Obviously, this requires submitting tests for features<br>
>>> that didn't have tests originally submitted.  But this would allow the<br>
>>> customer to have some of the new feature functionality of 14 in the 13<br>
>>> branch.<br>
>>><br>
>>> I know that isn't exactly what you were asking, but perhaps it might<br>
>>> be another possibility for those who really want to remain on an LTS.<br>
>>><br>
>>> Sorry to be the bearer of bad news on this :-(<br>
>>><br>
>>> --<br>
>>> Matthew Fredrickson<br>
>>> Digium, Inc. | Engineering Manager<br>
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
>>><br>
>>> --<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><br>
>><br>
>><br>
>><br>
>> So a compromise is having clients pay a developer to try and get those<br>
>> changes into 13? I don't really see that as a compromise personally. When<br>
>> those features were written, why weren't they written with tests and<br>
>> backported into 13? Because its more difficult and time consuming.<br>
>><br>
>> Its all semantics at the end of the day - whether you release 14 as 15 and<br>
>> then have 15 be a LTS and then release what is 15 beta to be 16 - its all<br>
>> just numbers. I don't want you to change your general policy on LTS version<br>
>> numbers specifically - I just want an LTS as described in the same wiki<br>
>> document you linked to - releasing 14.6 as an LTS is the way to do that.<br>
>><br>
>> I don't really understand how as an open source project you can have a<br>
>> public policy and then change that policy _just_ when people are expecting<br>
>> that policy to come into force - if 6 months ago you had said "15 has a load<br>
>> of changes in it and we want to break our LTS policy" then I'm sure people<br>
>> would have thought and planned a bit more - but at this time we're just over<br>
>> a month until Astricon where typically, the new version of Asterisk is<br>
>> released, where we were expecting an LTS. This really leaves a bitter taste<br>
>> in the mouth.<br>
>> --<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><br>
><br>
> --<br>
> Seán C McCord<br>
> CyCore Systems, Inc<br>
> <a href="tel:(888)%20240-0308" value="+18882400308" target="_blank">+1 888 240 0308</a><br>
> PGP/GPG: <a href="http://cycoresys.com/scm.asc" rel="noreferrer" target="_blank">http://cycoresys.com/scm.asc</a><br>
><br>
> --<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><br>
<br>
<br>
<br>
--<br>
Matthew Fredrickson<br>
Digium, Inc. | Engineering Manager<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
<br>
--<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><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Seán C McCord<div>CyCore Systems, Inc</div><div>+1 888 240 0308</div><div>PGP/GPG: <a href="http://cycoresys.com/scm.asc">http://cycoresys.com/scm.asc</a></div></div></div>