<?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: Firefox 3.5.5 by the (wall-clock) numbers</title>
	<atom:link href="http://oduinn.com/blog/2009/11/11/firefox-355-by-the-wall-clock-numbers/feed/" rel="self" type="application/rss+xml" />
	<link>http://oduinn.com/blog/2009/11/11/firefox-355-by-the-wall-clock-numbers/</link>
	<description></description>
	<lastBuildDate>Fri, 27 Jan 2012 15:12:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Firefox 3.6.6 by the (wall-clock) numbers - John O&#039;Duinn&#039;s Soapbox</title>
		<link>http://oduinn.com/blog/2009/11/11/firefox-355-by-the-wall-clock-numbers/#comment-47608</link>
		<dc:creator>Firefox 3.6.6 by the (wall-clock) numbers - John O&#039;Duinn&#039;s Soapbox</dc:creator>
		<pubDate>Tue, 29 Jun 2010 08:56:58 +0000</pubDate>
		<guid isPermaLink="false">http://oduinn.com/2009/11/11/firefox-355-by-the-wall-clock-numbers/#comment-47608</guid>
		<description>[...] Engineering portion of that was 10h 15m. By comparison, our previous fastest release turnaround was FF3.5.5 (3d 4h 45m from start to finish, with Release Engineering taking 13-16hours). For FF3.6.6, the times [...]</description>
		<content:encoded><![CDATA[<p>[...] Engineering portion of that was 10h 15m. By comparison, our previous fastest release turnaround was FF3.5.5 (3d 4h 45m from start to finish, with Release Engineering taking 13-16hours). For FF3.6.6, the times [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://oduinn.com/blog/2009/11/11/firefox-355-by-the-wall-clock-numbers/#comment-40330</link>
		<dc:creator>John</dc:creator>
		<pubDate>Sat, 21 Nov 2009 02:22:11 +0000</pubDate>
		<guid isPermaLink="false">http://oduinn.com/2009/11/11/firefox-355-by-the-wall-clock-numbers/#comment-40330</guid>
		<description>hi Ben;

I talked with Sam (ss) about this since posting this blog. 

I had (incorrectly) thought his &quot;go to mirrors&quot; email marked the end of QA / beta feedback, and marked our permission to start push to mirrors when RelEng next came to office EST. Hence my thinking we had room to improve. However, from talking with Sam, he clarified that he (and some others in QA) were still monitoring during the night and early morning, and could still potentially halt a release. We were just not notified when that monitoring stopped.

For future releases, Sam will send two emails:
1) one email, typically late at night, to forewarn RelEng of a likely &quot;go to mirrors&quot; the next morning, so we can plan accordingly.
2) next email, typically early next morning after Sam verifies no last minute QA / beta cycle problems are reported and RelEng should start mirror push asap.


The extra email prevents a possible situation where RelEng starts mirror push first thing in morning, thinking we already have permission, while at the same time, Sam is still investigating a newly found problem which could halt the release. It also helps clarify the wall-clock timing above, and will, I believe address your comment above.</description>
		<content:encoded><![CDATA[<p>hi Ben;</p>
<p>I talked with Sam (ss) about this since posting this blog. </p>
<p>I had (incorrectly) thought his &#8220;go to mirrors&#8221; email marked the end of QA / beta feedback, and marked our permission to start push to mirrors when RelEng next came to office EST. Hence my thinking we had room to improve. However, from talking with Sam, he clarified that he (and some others in QA) were still monitoring during the night and early morning, and could still potentially halt a release. We were just not notified when that monitoring stopped.</p>
<p>For future releases, Sam will send two emails:<br />
1) one email, typically late at night, to forewarn RelEng of a likely &#8220;go to mirrors&#8221; the next morning, so we can plan accordingly.<br />
2) next email, typically early next morning after Sam verifies no last minute QA / beta cycle problems are reported and RelEng should start mirror push asap.</p>
<p>The extra email prevents a possible situation where RelEng starts mirror push first thing in morning, thinking we already have permission, while at the same time, Sam is still investigating a newly found problem which could halt the release. It also helps clarify the wall-clock timing above, and will, I believe address your comment above.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Hearsum</title>
		<link>http://oduinn.com/blog/2009/11/11/firefox-355-by-the-wall-clock-numbers/#comment-40020</link>
		<dc:creator>Ben Hearsum</dc:creator>
		<pubDate>Wed, 11 Nov 2009 15:30:12 +0000</pubDate>
		<guid isPermaLink="false">http://oduinn.com/2009/11/11/firefox-355-by-the-wall-clock-numbers/#comment-40020</guid>
		<description>Great turnaround one this one, indeed.

I don&#039;t think it&#039;s correct to say there was &quot;8.5 hours of waiting between &#039;go to mirrors&#039; and &#039;mirror push started&#039;&quot;. In the e-mail sent late on Nov 4 we were instructed to push to mirrors next morning, not that night. That is to say, there wasn&#039;t 8 hours of unnecessary waiting here, as your original sentence implies.</description>
		<content:encoded><![CDATA[<p>Great turnaround one this one, indeed.</p>
<p>I don&#8217;t think it&#8217;s correct to say there was &#8220;8.5 hours of waiting between &#8216;go to mirrors&#8217; and &#8216;mirror push started&#8217;&#8221;. In the e-mail sent late on Nov 4 we were instructed to push to mirrors next morning, not that night. That is to say, there wasn&#8217;t 8 hours of unnecessary waiting here, as your original sentence implies.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

