<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: My thoughts on the reactions to the ESX 3.5 Update 2 BUG</title>
	<atom:link href="http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/feed/" rel="self" type="application/rss+xml" />
	<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/</link>
	<description>Go Green with Virtualization. Go UGLY Green with vmetc.com.</description>
	<lastBuildDate>Tue, 17 Apr 2012 03:50:42 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Jason Willey</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-1090</link>
		<dc:creator>Jason Willey</dc:creator>
		<pubDate>Thu, 21 Aug 2008 08:41:32 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-1090</guid>
		<description>Our support team practically begged for us to sanction this patch for us in production.    I told them that beyond the issue of having to test it in our environment, we never deploy any non security updates within the first thirty days.  We usually wait for the BEEs (Bleeding Edge Engineers) to test it and post on the forums.  I still find it hard to believe people had this progressed from posted on the VMware site to production within three weeks. 

Great point about the reputation damage at a time when the Microsoft marketing machine has the volume turned to eleven.  I received many calls from people I know all over the country asking me if we were impacted.   I can&#039;t remember the last time there was that much negative buzz about a product that we actually use.</description>
		<content:encoded><![CDATA[<p>Our support team practically begged for us to sanction this patch for us in production.    I told them that beyond the issue of having to test it in our environment, we never deploy any non security updates within the first thirty days.  We usually wait for the BEEs (Bleeding Edge Engineers) to test it and post on the forums.  I still find it hard to believe people had this progressed from posted on the VMware site to production within three weeks. </p>
<p>Great point about the reputation damage at a time when the Microsoft marketing machine has the volume turned to eleven.  I received many calls from people I know all over the country asking me if we were impacted.   I can&#8217;t remember the last time there was that much negative buzz about a product that we actually use.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Willey</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-5327</link>
		<dc:creator>Jason Willey</dc:creator>
		<pubDate>Thu, 21 Aug 2008 08:41:00 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-5327</guid>
		<description>Our support team practically begged for us to sanction this patch for us in production.    I told them that beyond the issue of having to test it in our environment, we never deploy any non security updates within the first thirty days.  We usually wait for the BEEs (Bleeding Edge Engineers) to test it and post on the forums.  I still find it hard to believe people had this progressed from posted on the VMware site to production within three weeks. 

Great point about the reputation damage at a time when the Microsoft marketing machine has the volume turned to eleven.  I received many calls from people I know all over the country asking me if we were impacted.   I can&#039;t remember the last time there was that much negative buzz about a product that we actually use.</description>
		<content:encoded><![CDATA[<p>Our support team practically begged for us to sanction this patch for us in production.    I told them that beyond the issue of having to test it in our environment, we never deploy any non security updates within the first thirty days.  We usually wait for the BEEs (Bleeding Edge Engineers) to test it and post on the forums.  I still find it hard to believe people had this progressed from posted on the VMware site to production within three weeks. </p>
<p>Great point about the reputation damage at a time when the Microsoft marketing machine has the volume turned to eleven.  I received many calls from people I know all over the country asking me if we were impacted.   I can&#8217;t remember the last time there was that much negative buzz about a product that we actually use.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Shelton</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-1040</link>
		<dc:creator>James Shelton</dc:creator>
		<pubDate>Sat, 16 Aug 2008 19:01:00 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-1040</guid>
		<description>Rich,

I&#039;m no professional developer either...but I have extensive experience installing and supporting infrastructure for several Fortune 500&#039;s. It&#039;s only logical that such date-triggered bugs would be practically impossible to properly vet in any testing process (I can think of other errors that would be equally difficult to detect and/or test for). Sure...in this particular case it was an actual expiring license....but what if it had been an actual programming error that triggered upon reaching some arbitrary date or time? My point is that there are some things that you cannot stop no matter your testing process. There is only one process that will ensure that you never are hit by these newly introduced errors or bugs...sit on your hands and never upgrade anything. Of course...there is a business cost to making that decision as well...it just takes longer to realize that problem... 

The fact is that software is only becoming more complex, more powerful, more difficult to fully test, more difficult to track, (you can see where I&#039;m going here...). Companies should develop strong change management procedures to attempt to mitigate issues like this...but no one should confuse the word &quot;mitigate&quot; with the word eliminate...because I can assure you...no process will eliminate the introduction of bugs, errors, or vulnerabilities into any company&#039;s production systems.</description>
		<content:encoded><![CDATA[<p>Rich,</p>
<p>I&#8217;m no professional developer either&#8230;but I have extensive experience installing and supporting infrastructure for several Fortune 500&#8242;s. It&#8217;s only logical that such date-triggered bugs would be practically impossible to properly vet in any testing process (I can think of other errors that would be equally difficult to detect and/or test for). Sure&#8230;in this particular case it was an actual expiring license&#8230;.but what if it had been an actual programming error that triggered upon reaching some arbitrary date or time? My point is that there are some things that you cannot stop no matter your testing process. There is only one process that will ensure that you never are hit by these newly introduced errors or bugs&#8230;sit on your hands and never upgrade anything. Of course&#8230;there is a business cost to making that decision as well&#8230;it just takes longer to realize that problem&#8230; </p>
<p>The fact is that software is only becoming more complex, more powerful, more difficult to fully test, more difficult to track, (you can see where I&#8217;m going here&#8230;). Companies should develop strong change management procedures to attempt to mitigate issues like this&#8230;but no one should confuse the word &#8220;mitigate&#8221; with the word eliminate&#8230;because I can assure you&#8230;no process will eliminate the introduction of bugs, errors, or vulnerabilities into any company&#8217;s production systems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Shelton</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-5326</link>
		<dc:creator>James Shelton</dc:creator>
		<pubDate>Sat, 16 Aug 2008 19:01:00 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-5326</guid>
		<description>Rich,

I&#039;m no professional developer either...but I have extensive experience installing and supporting infrastructure for several Fortune 500&#039;s. It&#039;s only logical that such date-triggered bugs would be practically impossible to properly vet in any testing process (I can think of other errors that would be equally difficult to detect and/or test for). Sure...in this particular case it was an actual expiring license....but what if it had been an actual programming error that triggered upon reaching some arbitrary date or time? My point is that there are some things that you cannot stop no matter your testing process. There is only one process that will ensure that you never are hit by these newly introduced errors or bugs...sit on your hands and never upgrade anything. Of course...there is a business cost to making that decision as well...it just takes longer to realize that problem... 

The fact is that software is only becoming more complex, more powerful, more difficult to fully test, more difficult to track, (you can see where I&#039;m going here...). Companies should develop strong change management procedures to attempt to mitigate issues like this...but no one should confuse the word &quot;mitigate&quot; with the word eliminate...because I can assure you...no process will eliminate the introduction of bugs, errors, or vulnerabilities into any company&#039;s production systems.</description>
		<content:encoded><![CDATA[<p>Rich,</p>
<p>I&#8217;m no professional developer either&#8230;but I have extensive experience installing and supporting infrastructure for several Fortune 500&#8242;s. It&#8217;s only logical that such date-triggered bugs would be practically impossible to properly vet in any testing process (I can think of other errors that would be equally difficult to detect and/or test for). Sure&#8230;in this particular case it was an actual expiring license&#8230;.but what if it had been an actual programming error that triggered upon reaching some arbitrary date or time? My point is that there are some things that you cannot stop no matter your testing process. There is only one process that will ensure that you never are hit by these newly introduced errors or bugs&#8230;sit on your hands and never upgrade anything. Of course&#8230;there is a business cost to making that decision as well&#8230;it just takes longer to realize that problem&#8230; </p>
<p>The fact is that software is only becoming more complex, more powerful, more difficult to fully test, more difficult to track, (you can see where I&#8217;m going here&#8230;). Companies should develop strong change management procedures to attempt to mitigate issues like this&#8230;but no one should confuse the word &#8220;mitigate&#8221; with the word eliminate&#8230;because I can assure you&#8230;no process will eliminate the introduction of bugs, errors, or vulnerabilities into any company&#8217;s production systems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rich</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-1036</link>
		<dc:creator>Rich</dc:creator>
		<pubDate>Sat, 16 Aug 2008 09:09:26 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-1036</guid>
		<description>James,

I&#039;m not a developer, and I&#039;ve had limited personal experience administrating infrastructure for product development, but it&#039;s my understanding that conducting tests to determine if the licenses expire at any date would not be attempted. What should catch something like this is a QA process that tracks if the release candidate&#039;s expiration code has been disabled in the final version that goes to general availability.</description>
		<content:encoded><![CDATA[<p>James,</p>
<p>I&#8217;m not a developer, and I&#8217;ve had limited personal experience administrating infrastructure for product development, but it&#8217;s my understanding that conducting tests to determine if the licenses expire at any date would not be attempted. What should catch something like this is a QA process that tracks if the release candidate&#8217;s expiration code has been disabled in the final version that goes to general availability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rbrambley</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-5325</link>
		<dc:creator>rbrambley</dc:creator>
		<pubDate>Sat, 16 Aug 2008 09:09:00 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-5325</guid>
		<description>James,

I&#039;m not a developer, and I&#039;ve had limited personal experience administrating infrastructure for product development, but it&#039;s my understanding that conducting tests to determine if the licenses expire at any date would not be attempted. What should catch something like this is a QA process that tracks if the release candidate&#039;s expiration code has been disabled in the final version that goes to general availability.</description>
		<content:encoded><![CDATA[<p>James,</p>
<p>I&#8217;m not a developer, and I&#8217;ve had limited personal experience administrating infrastructure for product development, but it&#8217;s my understanding that conducting tests to determine if the licenses expire at any date would not be attempted. What should catch something like this is a QA process that tracks if the release candidate&#8217;s expiration code has been disabled in the final version that goes to general availability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Shelton</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-1031</link>
		<dc:creator>James Shelton</dc:creator>
		<pubDate>Sat, 16 Aug 2008 04:03:18 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-1031</guid>
		<description>I&#039;d just like to add that no amount of &quot;Change Control&quot; will prevent all date triggered catastrophes like this. This date could have just as easily been many weeks or months in the future and could have been rolled out to production by even some of the most conservative of procedures and been subsequently nailed with the bug anyway. I guess the old bumper sticker is true...it just &quot;Happens&quot;.</description>
		<content:encoded><![CDATA[<p>I&#8217;d just like to add that no amount of &#8220;Change Control&#8221; will prevent all date triggered catastrophes like this. This date could have just as easily been many weeks or months in the future and could have been rolled out to production by even some of the most conservative of procedures and been subsequently nailed with the bug anyway. I guess the old bumper sticker is true&#8230;it just &#8220;Happens&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Shelton</title>
		<link>http://vmetc.com/2008/08/13/my-thoughts-on-the-reactions-to-the-esx-35-update-2-bug/comment-page-1/#comment-5324</link>
		<dc:creator>James Shelton</dc:creator>
		<pubDate>Sat, 16 Aug 2008 04:03:00 +0000</pubDate>
		<guid isPermaLink="false">http://vmetc.com/?p=577#comment-5324</guid>
		<description>I&#039;d just like to add that no amount of &quot;Change Control&quot; will prevent all date triggered catastrophes like this. This date could have just as easily been many weeks or months in the future and could have been rolled out to production by even some of the most conservative of procedures and been subsequently nailed with the bug anyway. I guess the old bumper sticker is true...it just &quot;Happens&quot;.</description>
		<content:encoded><![CDATA[<p>I&#8217;d just like to add that no amount of &#8220;Change Control&#8221; will prevent all date triggered catastrophes like this. This date could have just as easily been many weeks or months in the future and could have been rolled out to production by even some of the most conservative of procedures and been subsequently nailed with the bug anyway. I guess the old bumper sticker is true&#8230;it just &#8220;Happens&#8221;.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

