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

[Olle E. Johansson]

16 aug 2012 kl. 15:20 skrev Matthew Jordan:

> 
> ----- Original Message -----
>> From: "Russell Bryant" <russell at russellbryant.net>
>> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
>> Sent: Thursday, August 16, 2012 7:31:04 AM
>> Subject: [asterisk-dev] Removing res_jabber, chan_gtalk, chan_jingle?
>> 
>> Greetings,
>> 
>> I noticed that res_jabber, chan_gtalk, and chan_jingle are still in
>> Asterisk 11 and trunk.  Now that we have chan_motif and res_xmpp,
>> should the old modules be removed?  It seems to me that they should.
>> If not, why not?
>> 
> 
> Probably just to err on the side of caution.  In the case of res_jabber,
> it probably could be marked as deprecated, as res_xmpp is a drop in
> replacement for it.  I'd still prefer to keep it in Asterisk 11 to ease
> the upgrade burden on people.
> 
> Its arguable that chan_motif is not a drop in replacement for both
> chan_jingle and chan_gtalk.  Keeping them 'extended' for a release
> and then reevaluating the status of those channel drivers for Asterisk 12
> seems reasonable.
> 

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.

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.

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 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. 



/O