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

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

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! :-)

--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org