[asterisk-dev] Thoughts on Asterisk release management

[Mihai Balea]

On Sep 19, 2007, at 7:24 PM, Russell Bryant wrote:

> .......
> I think if we could get some community buy in on this, we will be  
> dealing with
> much fewer new bugs at a time, which will make Asterisk a lot more  
> stable in the
> end.  I really don't want to deal with building up a year to a year  
> and a half
> of changes before people actually start using them ever again.
>
> What do you think?  Does this sound like a good idea?  Would people  
> buy in to
> this and actually use the 1.5 releases?  If not, I am very  
> interested to hear
> any other ideas people have that may improve the way we manage  
> releases.  Feel
> free to point out other large open source projects that have  
> release management
> that you find especially successful.

This is a good start, but I believe it will have a somewhat limited  
effect.  There will be a larger number of people that will try out  
the new RC versions, but only on limited, small scale systems.  This  
will uncover some bugs but will be ineffective in outing an entire  
class of problems that appear only under heavy usage and in large  
deployments.

You have to understand that Asterisk is a mature product.  A lot more  
people use it as a core revenue generator or as part of essential  
business infrastructure now than a few years ago, in the 1.0 and 1.2  
days.  These people will need massive incentives to assume the risk  
of moving to a new and unproven version - by incentives I mean  
compelling new features and a proven track of reliability.  Also,  
many people have been burned by the 1.4 upgrade, so they will think  
twice before attempting another one anytime soon.  So don't be  
surprised if the 1.5 adoption will not b as wide as you hoped for.

I would like to offer a suggestion:  reduce the release interval to  
more than one stable release per year.  I believe that a 6 months  
release cycle would be more manageable.  The changes between releases  
will be less radical and it will create more "stable points" in the  
timeline of the product.  This would create larger set of available  
releases, so people could choose according to their risk tolerance  
and desire for new features.  Somebody that needs the latest features  
does not need to wait up to a year for a stable release and at the  
same time somebody who's very risk averse can stay one or two  
releases behind.  Obviously, this will mean more maintenance work,  
since more branches will be active at any given time, but I believe  
it's worth it.

As an aside, I believe that Asterisk needs more test harnesses.  The  
issue of people not wanting to deploy new versions on large systems  
can be partially alleviated by a set of comprehensive load and stress  
tests.  We are beginning to do that for chan_iax2, since this is what  
we're focusing on, but I believe that many other components can  
benefit from a similar approach.  If people would take the time and  
create some test harnesses for their area of interest, we could  
accumulate a set of tests that can be extremely helpful in increasing  
the general confidence levels.

Anyways, just my $0.02

Cheers,
Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2411 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070920/323a04f0/attachment.bin