[Asterisk-Dev] backporting persisent queues?

[Eric Wieling]

Greg Boehnlein wrote:

> On Fri, 8 Apr 2005, Jerris, Michael MI wrote:
> 
> 
>>Now this could be a worthwhile use for the patches stuff in the makefile
>>that mark had been playing with.  Then again, a much better way to do
>>this would be to try to set a more frequent release schedule, that would
>>keep us from having features unavailable to "stable" users for so long.
>>Anyone for a 3 month cycle, head-->test-->release, shifting down 1 level
>>every 3 months or so?  What do we need in place for "testing" for this
>>to be worthwhile?
> 
> 
> If it were software for virtually anything else, I'd agree with you, but 
> quite frankly, PBX software should have pretty long development, test and 
> release cycles. People don't take to kindly to their phone calls just 
> getting hung up on n such.. As many changes that have gone into head, we 
> should really let things flesh out for a while, keep adding fixes and at 
> some point in the future announce a code freeze and just work on bug fixes 
> before turning head into stable.

Asterisk does not have a long test cycle.  It has a long development 
cycle where lots of new features are added, then what always seems to 
me like a "let's just release the damn thing and to hell with a long 
test cycle" policy.

Asterisk is both a young piece of software and a complex piece of 
software.  You expect rapid development and many changes as features 
are added and removed.

Here's an example.  You want to get extension routing information from 
a remote place.  First there was the switch => statement, then the 
1.0.x database stuff, then SRV record support, and then DUNDI, then 
the CVS-HEAD Realtime stuff.

All of these things let you get extensions out of extensions.conf into 
something that works sort of like a database.  Which one is best? 
Hell if I know.  Each has it's advantages and disadvantages.  It seems 
to me that switch => and 1.0.x database stuff should go away.  They 
were tried and eventually people realized that there were better ways 
of doing things.  This is the way young software works.

-- 
Always do right. This will gratify some people and astonish the rest.
Mark Twain