[asterisk-dev] Removing res_jabber, chan_gtalk, chan_jingle?

[Olle E. Johansson]

16 aug 2012 kl. 17:09 skrev Andrew Latham:

> On Thu, Aug 16, 2012 at 11:05 AM, Olle E. Johansson <oej at edvina.net> wrote:
>> 
>> 16 aug 2012 kl. 16:58 skrev Matthew Jordan:
>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Olle E. Johansson" <oej at edvina.net>
>>>> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
>>>> Sent: Thursday, August 16, 2012 9:34:28 AM
>>>> Subject: Re: [asterisk-dev] Removing res_jabber, chan_gtalk, chan_jingle?
>>>> 
>>>> 
>>>> 
>>>> I really think we need to revisit the policy for naming a release
>>>> LTS. If a completely new module
>>>> is supposed to enter LTS state in the first release after commit -
>>>> and replace the old modules - it is
>>>> very very scary for those of us using Asterisk in production.
>>> 
>>> Your fear regarding a new channel driver in an LTS version is completely
>>> understandable.
>>> 
>>> In this particular case, we arrived at this decision after seeing how
>>> difficult it was to maintain - in any reasonable fashion - chan_gtalk and
>>> chan_jingle.  We tried to maintain them ourselves and found ourselves
>>> thrashing on changes between Google and ourselves, that were a result of
>>> problems in the design of the channel drivers.  We tried to maintain them
>>> in collaboration with the developer community (see
>>> https://wiki.asterisk.org/wiki/display/AST/Help+Maintain+Google+Talk+and+Voice
>>> and http://lists.digium.com/pipermail/asterisk-dev/2011-August/050766.html) -
>>> the end result was the same.
>>> 
>>> When the problem is a fundamental design flaw in those channel drivers,
>>> no amount of band-aids is going to result in a good maintenance experience
>>> for end users.
>>> 
>>> The decision to go with a new channel driver was not made lightly.  I sincerely
>>> believe that it was the correct decision in this particular case.
>>> 
>>>> In my world, we are considering the upgrade to 1.8, a release that is
>>>> slowly becoming stable enough to be
>>>> used in production, which means LTS for us - or PQ, Production
>>>> Quality. It's time to leave 1.4 that is
>>>> a stable workhorse.
>>>> 
>>>> We might want to combine the idea of certified and LTS into something
>>>> that is boring, but at least have
>>>> survived two development releases before being included in something
>>>> that is LTS/Certified.
>>> 
>>> We haven't been using the model of LTS/Standard release for very long.  As it
>>> is, I'd say that we've done it now for only three releases (one of which
>>> happens to have just entered beta!) - so I'd prefer to keep this model going
>>> until we're sure we have enough evidence to change it.
>>> 
>>> 1.8 - LTS
>>> 10 - lots of new architecture internally to support media, major app changes/fax
>>>    changes
>>> 11 - LTS
>>> 
>>> The 'biggest' changes in 11 are arguably chan_motif, WebSockets, and ICE
>>> support.  All of those are optional and did not fundamentally alter the internal
>>> architecture of Asterisk.  WebSockets can just not be used; ICE can be disabled;
>>> chan_motif can not be used in favor of chan_gtalk/chan_jingle.  I still see
>>> Asterisk 11 as a logical LTS release and an extension of Asterisk 10.
>>> 
>>>> In addition we need a policy on how to handle experimental code. It
>>>> should not be part of LTS, really.
>>>> And it should not be experimental in release after release. Fix it,
>>>> keep it in external branches or remove it.
>>> 
>>> The closest thing we have to 'experimental' code at this point is WebSockets.
>>> That's more a function of the state of things in the IETF, and not because
>>> I feel that the code is not as well tested as Josh could make it before beta.
>>> 
>>> As far as WebSockets go - again, it is at least faily non-invasive.  You'll note
>>> that we've committed to supporting it in Asterisk 11+ as a core supported
>>> feature.  As far as something that could at least theoretically be viewed as
>>> 'experimental', that's a pretty strong commitment on our part.
>> Who is "our" part that committed to this?
>> 
>>> 
>>> I'm not sure what else you're referring to in Asterisk 11 that would fall under
>>> that category.
>>> 
>>>> The situation we have now with five downloads on the web site is not
>>>> a good solution. Confusing
>>>> your users is not a good policy. We need to clean up and base the
>>>> clean up on a developer community
>>>> discussion in the open.
>>>> 
>>> 
>>> The website is under going a transition period, which should help alleviate
>>> some of the download issues.
>>> 
>>> As far as things being communicated in the open - we've always preferred to have
>>> our communication on the asterisk-dev mailing list.  I certainly don't expect
>>> that to change! :-)
>> 
>> 
>> Well, can you point me to the discussion on the -dev list that lead to the
>> decision to release a "certified" code base?
>> 
>> It's something that I can't find and it's released on the asterisk.org project
>> web site, where I don't think it belong. Like the Digium proprietary phone code.
>> That's not a community thing that we discussed either.
>> 
>> /O
>> 
>> 
>> --
> 
> Olle
> 
> All of the Certified and phone stuff was in one email.
> http://lists.digium.com/pipermail/asterisk-dev/2012-July/055887.html

That's my point. It was never discussed in the dev group, we never got a chance to
discuss this in relationship to the current release policies. It's kind of 
"What you've decided is not good enough so we're off to do something else in addition to your work"

Well, thank you. It's very hard to explain to customers - why isn't one LTS good enough? What's wrong with that release?

/O