asterisk users - Feb 2003 - Re: [Asterisk] Software quality control

> Personally, I run CVS on production equipment.  If it doesn't compile,
> I don't install it.  :-)
This practice is too frightening to even imagine.  If our phone system
hiccups, people start screaming.  If it stopped working for an hour,
someone could lose their job.

Having a known-working, well-tested, stable version of Asterisk that I
could trust to not crash - even if doesn't have all the bells and
whistles - would allow me to put Asterisk into production here at the
Hospital where I maintain the network.  "Current CVS" is never tested
more than a month since the last change.  I run "current CVS" at
another
site with fewer users, where they are much more tolerant of service
outages (mainly because the service runs over a wireless link that is
not 100% reliable anyway).

I strongly support keeping three versions of Asterisk:
  1. STABLE      - tested for extended period with no known critical
                   bugs (for use in production).
  2. TESTING     - snapshot of CVS that is undergoing field testing
  3. CURRENT CVS - bleeding-edge, development version

Periodically, Mark could tag a version of the CVS that he's comfortable
with for extended testing.  This would be called TESTING. Then, I could
install that in my "friendly" site and give it some mileage.  After
this
version has been working without problems for some length of time, it
would replace the current STABLE snapshot.

Whenever enough people build up enough confidence in the TESTING
version, it could move to STABLE, and Mark could pick a version of CVS
that he thinks will not fall down right away, and make a new TESTING.
The only difficult part would be maintaining the TESTING version as
fixes are applied to it to make it more "stable".

Sincerely
Bill Jennings
Jennings Computing Services

On Fri, 2003-02-14 at 10:47, Bill Jennings wrote:
> Having a known-working, well-tested, stable version of Asterisk that I
> could trust to not crash - even if doesn't have all the bells and
> whistles - would allow me to put Asterisk into production here at the
> Hospital where I maintain the network.  "Current CVS" is never
tested
> more than a month since the last change.  I run "current CVS" at
another
> site with fewer users, where they are much more tolerant of service
> outages (mainly because the service runs over a wireless link that is
> not 100% reliable anyway).
> 
> I strongly support keeping three versions of Asterisk:
>   1. STABLE      - tested for extended period with no known critical
>                    bugs (for use in production).
>   2. TESTING     - snapshot of CVS that is undergoing field testing
>   3. CURRENT CVS - bleeding-edge, development version
> 
> Periodically, Mark could tag a version of the CVS that he's comfortable
> with for extended testing.  This would be called TESTING. Then, I could
> install that in my "friendly" site and give it some mileage. 
After this
> version has been working without problems for some length of time, it
> would replace the current STABLE snapshot.
> 
> Whenever enough people build up enough confidence in the TESTING
> version, it could move to STABLE, and Mark could pick a version of CVS
> that he thinks will not fall down right away, and make a new TESTING.
> The only difficult part would be maintaining the TESTING version as
> fixes are applied to it to make it more "stable".
Since CVS makes all revisions available, you can essentially do the same
thing yourself. You mentioned you have a testing capable environment,
and you can upgrade it from time to time keeping track of the cvs
checkout date. When you feel you have a stable system you can upgrade
the more critical system.

You will find many of us are running CVS on production systems.  I do
checkouts occasionally for our PBX at work. Updates are not done very
often at work due to not wanting to take asterisk down. You will
probably also note that if you are in a critical situation, like the
hospital you mentioned, you need to setup failover options.  You also
will probably have to schedule your upgrades in phases over your
failover options. You will have to design a lot more into a hospital pbx
than branching of the cvs tree.

-- 
Steven Critchfield <critch at basesys.com>