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