Well - I mostly was objecting to the idea of 'patching more frequently'
without some structure and reasoning behind it.  Patching just to patch
isn't really a strategy.

But yes - I would agree that it is usually better to apply a few patches at
once rather than many, for the reasons you state.  So there is an argument
there for 'more frequently'.   But there's another argument, like stability
- which would rather reduce down times to the fewest instances possible --
and do a single large multiple patch rather then several small ones - to
reduce the number of potential outages.

Anyway - we need more info about the 'why' of being requested to patch more
frequently...   is there an intent or strategy behind it -- or is it coming
from someone who just thinks 'more is better'?   I still think a policy
needs to be defined and put in place if it is not already, and then talk
about frequency of patches in that context.

Scott Rohling


On Thu, Aug 18, 2011 at 12:37 PM, Clovis Pereira <gclo...@br.ibm.com> wrote:

> Scott, only to feed this discussion:
> Apply 5 patchs by month looks better than 15 by quarter or 30 by
> half-year. Less corrections is faster, easy to analyze and less
> problematic to fallback, if needed.
> Is it a valid argument?
> Regards,
>
> PS. Only ideas, I don't work in the Linux team. Don't know the practical
> issues...
> ______________________________________________
> Clovis
>
>
>
> From:
> Scott Rohling <scott.rohl...@gmail.com>
> To:
> LINUX-390@vm.marist.edu
> Date:
> 18/08/2011 13:17
> Subject:
> Re: patching frequency
> Sent by:
> Linux on 390 Port <LINUX-390@vm.marist.edu>
>
>
>
> If someone told me to patch more frequently - I would make them explain
> exactly how often and why.   For convenience sake, patching every x weeks
> or
> months might be nice .. but there should be policies in place that
> distinguish between security fixes and other types, and give
> rules/guidelines for how soon such patches should be applied.   If these
> policies don't exist - they should be developed - so I would be working to
> define that.
>
> There are so many approaches to patching..  'if it ain't broke, don't fix
> it' - 'stay a release behind current' - 'apply security fixes immediately'
> .. that being told 'patch more frequently' doesn't really give you much to
> go on.  What is your strategy when it comes to software maintenance?  What
> are the policies that must be adhered to?  What are the maintenance
> windows
> that allow you to patch servers? Those seem like better indicators then
> 'frequency'.
>
> Scott Rohling
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
>
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to