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

[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

-- 
~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~