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

[Olle E. Johansson]

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