[VoiceOps] Broadworks Patch Religion

[Justin Randall]

My original reply still applies to patch dependencies.

IMHO if one needs certain patches to address negatively impacting
behaviour, one looks into all of the dependencies required, perform the
appropriate lab testing, and then deploy if all lab testing and
pre-production soak periods have passed without problems.  If there are
any problems in testing, one has to consider which bugs/behaviours are
worse to live with for the time being and make a judgement call.

Really it's all about trade-offs, some prefer to take the extra time and
be more thorough and others like to take extra risks to be more nimble.

I'm more in favor of being as thorough as possible and taking the time
to ensure as smooth of a patch rollout as possible to mitigate as much
risk as possible relating to new bugs and/or unwanted behaviours.

Regards,

Justin Randall
-----Original Message-----
From: voiceops-bounces at voiceops.org
[mailto:voiceops-bounces at voiceops.org] On Behalf Of Jason Warner
Sent: Wednesday, February 03, 2010 4:11 PM
To: David Hiers; VoiceOps at voiceops.org
Subject: Re: [VoiceOps] Broadworks Patch Religion

The problem with this approach is that you get so far behind on patches
that when you need to apply a specific patch you can't because of patch
dependencies.  You often cannot apply only the patches you want because
of this.  With as many patches released by Broadsoft, tracking the
dependencies and which patches you need to apply in order to apply the
patch(es) you need becomes problematic.  The longer you wait, the more
problematic it becomes.

-Jason Warner

----- Original Message -----
From: "Justin Randall" <jrandall at comwave.net>
To: "David Hiers" <hiersd at gmail.com>, VoiceOps at voiceops.org
Sent: Wednesday, February 3, 2010 12:19:43 PM
Subject: Re: [VoiceOps] Broadworks Patch Religion

With almost any piece of vendor software, patching always carries the
risk of introducing newer (and potentially more harmful) bugs.

While Broadsoft does a good job of attempting to document the interfaces
impacted by each patch, unless something is not working correctly in
your deployment, it's probably best to go by the approach of "if it
isn't broken, don't fix it".  I know they have an N-2 support policy but
this is main release and service pack based so it's not like you
couldn't get support or further patches for your issues because you
haven't installed the latest patch bundle or AP.

AFAIK on R16 you don't even need to upgrade SPs at all and can simply
stick with the R16 main release and add whichever patches you require.

Regards,

Justin Randall

-----Original Message-----
From: voiceops-bounces at voiceops.org
[mailto:voiceops-bounces at voiceops.org] On Behalf Of David Hiers
Sent: Tuesday, February 02, 2010 3:00 PM
To: VoiceOps at voiceops.org
Subject: [VoiceOps] Broadworks Patch Religion

For our entire history with BW, we've carefully researched and
selected individual patches to apply based on the functions that we
use and the issues that we see.

BW explicitly states that "customers can pick and choose the patches
they want", and they make it easy for us to do so.  This process has
worked quite well for us so far.  It takes a good deal of effort to
keep up with over 1 patch per day across the entire BW universe of
products, but we've done it and had good results.

Recently, the "open you mouth and close your eyes" idea has been
advanced, in which we would apply ALL patches, regardless of function
or issue.  We'd wait 30 days or so to let everyone else find the
problems with the contents of the default patch bundle, then just slap
the bundle on without any thinking.  We'd still test like chimps on
crack after patching, of course.

Are you picky or promiscuous with your BW patches?

Since this discussion is very vendor/version specific, we run BW R14sp9.


Thanks,


David Hiers
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops