I think that the answer you gave ignores application specific things.<div><br></div><div>For example, at a former employer, some code we had broke when Microsoft issued a service pack. Our code depended on the [broken] way NT would parse command line options, and that "was fixed" in the service pack. </div>
<div><br></div><div>Red Hat et al seem to be pretty good about just issuing real bug fixes and not jumping software versions during updates, but I don't get any warm fuzzies from the updates being regression tested. I would make sure to test anything related with the language you're using.</div>
<div><br></div><div>Another example, the version of Ruby that used to be in CentOS failed this test:</div><div><br></div><div>should "not have that 1.8.5 bigdecimal bug" do</div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>assert_equal "$1.01", ("$%0.2f" % BigDecimal.new("1.01"))</div>
<div>end</div></div><div><br></div><div>which is roughly the equivalent of sprintf("$%0.2f", 1.01) (it returned "$1.10", not something you want when you're producing financial reports)</div><div><br>
</div><div>Sean</div><div><br></div><div><br><div class="gmail_quote">On Mon, Nov 29, 2010 at 4:55 PM, John Lange <span dir="ltr"><<a href="mailto:john@johnlange.ca">john@johnlange.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In theory, regression testing is what you get when you use the the<br>
licensed versions of RedHat and Suse etc. so if your asking those<br>
kinds of questions you might want to use a licensed version.<br>
<br>
But I'm wondering what other people on this list think about that answer?<br>
<br>
>From my personal perspective, on our licensed versions of SLES as well<br>
as my desktop OpenSUSE I allow auto-update of everything that does not<br>
require a reboot.<br>
<br>
Since I'm stuck with proprietary ATI drivers on my laptop, if I allow<br>
auto-kernel updates my display stops working. On servers, unscheduled<br>
unsupervised rebooting is not a good idea so better to plan those<br>
updates.<br>
<br>
--<br>
John Lange<br>
<a href="http://www.johnlange.ca" target="_blank">www.johnlange.ca</a><br>
<br>
On Mon, Nov 29, 2010 at 11:33 AM, Gilbert E. Detillieux<br>
<<a href="mailto:gedetil@cs.umanitoba.ca">gedetil@cs.umanitoba.ca</a>> wrote:<br>
> On 2010-11-26 20:43, Adam Thompson wrote:<br>
>> For CentOS, I'm quite comfortable setting up automatic updates.<br>
>> It's not "best practices" but I've spent a LOT less time fixing<br>
>> post-update problems than I would have spent testing each update,<br>
>> over the years. (This applies to Red Hat in general since RH2.1.)<br>
><br>
> I would tend to agree here, at least for the repos enabled by default in<br>
> CentOS-Base.repo, i.e. base, updates, addons and extras. What I do at<br>
> work is allow auto-updates for those repos on the various workstations<br>
> and non-critical servers I maintain. For my most critical server, I run<br>
> "yum update" manually, after I've determined that the updates didn't<br>
> break anything on the other systems.<br>
><br>
> Not necessarily safe for third-party repos, however... I've had some<br>
> minor breakage with rpmforge packages, and catastrophic failures with<br>
> some EPEL updates that were DOA and pushed out without the slightest bit<br>
> of testing. (They can also take forever to fix such broken packages.)<br>
> I'd be sure to test these out on the least critical systems first,<br>
> before updating anything important.<br>
><br>
>> I think the days of testing patches independently are gone because of<br>
>> manpower reasons, unless you're running in a high-availability<br>
>> environment.<br>
><br>
> Again, I mostly agree, but I would make exceptions for certain critical<br>
> packages and/or critical systems, whether HA or not. But, yeah, you<br>
> can't test every update that comes out.<br>
><br>
> --<br>
> Gilbert E. Detillieux E-mail: <<a href="mailto:gedetil@muug.mb.ca">gedetil@muug.mb.ca</a>><br>
> Manitoba UNIX User Group Web: <a href="http://www.muug.mb.ca/" target="_blank">http://www.muug.mb.ca/</a><br>
> PO Box 130 St-Boniface Phone: (204)474-8161<br>
> Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609<br>
> _______________________________________________<br>
> Roundtable mailing list<br>
> <a href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
> <a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
><br>
<br>
_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Sean Walberg <<a href="mailto:sean@ertw.com">sean@ertw.com</a>> <a href="http://ertw.com/">http://ertw.com/</a><br>
</div>