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

[Paul Belanger]

On 12-08-16 10:34 AM, Olle E. Johansson wrote:
>
> 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.
>
I actually want to get together with a group of people at astri(dev)con 
and hash out some ideas about this.  Specifically integrators managing 
multiple asterisk production boxes.  I definitely think there is a 
difference of opinions on this subject between developers, implementers 
and end users.

> 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.
>
I think it is safe to say the first few releases of a new branch, might 
have some stability issues.  From what I see, it is simply because the 
lack of people that actually test Beta and RC releases before the .0 
release. Additionally should we even bother doing RCs (that is a 
different discussion I want to have too[1]).

Just look to the 1.8 branch for example, for us, anything before 1.8.7.1 
seems to have some significant issue (eg: 1.8.4 and Cisco phones).  This 
is why we have chosen 1.8.7.1 as our base release.  For what we do, it 
seems fairly stable.

> 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.
>
IMO certified asterisk and LTS would never be combined into a single 
release, unless we are willing to have Digium control the flow of fixes 
within that branch.  I understand why they created the branch, however 
we (the open source community) have no really control of it, Digium 
customers do.

> 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.
>
I really like how the Linux kernel handles this, Linux Next[2].  It is 
actually maintained by another team outside main stream, when people 
decided code is stable enough to be merged from next into main, it is 
actually very simple to do.  I'm not sure if we can do something like 
that or not.

> 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.
>
Agreed.  For me, it is virtually impossible to keep up with the amount 
of releases we do for asterisk.  And one of the reasons we are still 
using 1.8.7.1. I personally think we are doing too much active 
development on release branches to expect an integrator to keep up with 
that branch.

One change that could be made is, stop merging forward fixes (eg: fix in 
1.8, then merge to 10, then trunk).  And only fix said bug in trunk and 
decided to backport into 1.8 / 10 depending on the severity of the 
issue.  How to decide which bug gets fixes is another story, but this 
would help drastically reduce the amount of releases for each branch.

Like I said, lots of people have ideas on how this should work, but it 
would be cool if we could hash them out and come up with a plan.

[1] 
https://wiki.asterisk.org/wiki/display/~pabelanger/Asterisk+Release+Candidates
[2] http://www.kernel.org/pub/linux/kernel/next/

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger