<?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"
	>
<channel>
	<title>Comments on: productive testing tips</title>
	<atom:link href="http://tieguy.org/blog/2007/03/18/productive-testing-tips/feed/" rel="self" type="application/rss+xml" />
	<link>http://tieguy.org/blog/2007/03/18/productive-testing-tips/</link>
	<description>Ramblings on law school in New York, free software, and the spaces in between.</description>
	<pubDate>Wed, 03 Dec 2008 02:31:06 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: stephen o'grady</title>
		<link>http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9329</link>
		<dc:creator>stephen o'grady</dc:creator>
		<pubDate>Sun, 18 Mar 2007 23:36:26 +0000</pubDate>
		<guid isPermaLink="false">http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9329</guid>
		<description>@andre: excellent news: will look forward to that. i don't mind following instructions like &lt;a href="http://live.gnome.org/GettingTraces/DistroSpecificInstructions" rel="nofollow"&gt;these&lt;/a&gt;, but would argue that i'm probably in the minority.</description>
		<content:encoded><![CDATA[<p>@andre: excellent news: will look forward to that. i don&#8217;t mind following instructions like <a href="http://live.gnome.org/GettingTraces/DistroSpecificInstructions" rel="nofollow">these</a>, but would argue that i&#8217;m probably in the minority.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luis</title>
		<link>http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9325</link>
		<dc:creator>Luis</dc:creator>
		<pubDate>Sun, 18 Mar 2007 22:43:49 +0000</pubDate>
		<guid isPermaLink="false">http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9325</guid>
		<description>Chris: Whether you'll be testing stable or unstable depends on a lot of things, including developer availability, project priorities, etc., which were beyond the scope of my comment. The point I was trying to get across was that you need to use the latest version of whatever you're trying to test. That means that if your purpose is to test the stable branch, you need to be building out of stable branch revision control which the next tarballs will come from, rather than the last released set of tarballs. Hope that is more clear.</description>
		<content:encoded><![CDATA[<p>Chris: Whether you&#8217;ll be testing stable or unstable depends on a lot of things, including developer availability, project priorities, etc., which were beyond the scope of my comment. The point I was trying to get across was that you need to use the latest version of whatever you&#8217;re trying to test. That means that if your purpose is to test the stable branch, you need to be building out of stable branch revision control which the next tarballs will come from, rather than the last released set of tarballs. Hope that is more clear.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: andre</title>
		<link>http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9320</link>
		<dc:creator>andre</dc:creator>
		<pubDate>Sun, 18 Mar 2007 21:55:49 +0000</pubDate>
		<guid isPermaLink="false">http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9320</guid>
		<description>@stephen: the user would have to install additional debug *packages* to provide a better stacktrace. we hope that for 2.20, we will be able to use the google airbag code to workaround this problem.</description>
		<content:encoded><![CDATA[<p>@stephen: the user would have to install additional debug *packages* to provide a better stacktrace. we hope that for 2.20, we will be able to use the google airbag code to workaround this problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9312</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Sun, 18 Mar 2007 16:49:35 +0000</pubDate>
		<guid isPermaLink="false">http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9312</guid>
		<description>"2. Where possible, use the very latest code"

I think there is too much emphasis on the latest code. How about fixing issues in current releases instead of always pointing to new releases?

I am talking from a users point of view where I always have to upgrade to the latest version just to get fixes that should go into the current version (Firefox, Gnome etc.)</description>
		<content:encoded><![CDATA[<p>&#8220;2. Where possible, use the very latest code&#8221;</p>
<p>I think there is too much emphasis on the latest code. How about fixing issues in current releases instead of always pointing to new releases?</p>
<p>I am talking from a users point of view where I always have to upgrade to the latest version just to get fixes that should go into the current version (Firefox, Gnome etc.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: stephen o'grady</title>
		<link>http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9309</link>
		<dc:creator>stephen o'grady</dc:creator>
		<pubDate>Sun, 18 Mar 2007 16:00:38 +0000</pubDate>
		<guid isPermaLink="false">http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-9309</guid>
		<description>"every major OS now has ways to catch stack traces of catches and send them back to a bug database"

it would also help if the tools would automate the activation of debug flags or other necessary information; most of the stack traces i've submitted have come back with messages like the following:

"Unfortunately the stacktrace does not have any hints about the real cause of the crash and does not help in debugging this issue."</description>
		<content:encoded><![CDATA[<p>&#8220;every major OS now has ways to catch stack traces of catches and send them back to a bug database&#8221;</p>
<p>it would also help if the tools would automate the activation of debug flags or other necessary information; most of the stack traces i&#8217;ve submitted have come back with messages like the following:</p>
<p>&#8220;Unfortunately the stacktrace does not have any hints about the real cause of the crash and does not help in debugging this issue.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Slawek's Tech Hideout</title>
		<link>http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-11841</link>
		<dc:creator>Slawek's Tech Hideout</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://tieguy.org/blog/2007/03/18/productive-testing-tips/#comment-11841</guid>
		<description>&lt;!--%kramer-pre%--&gt;Zapomniałeś zapłacić rachunek ? Billreminder ci o tym przypomni. Więcej oraz przykładowe screenshot'y na stronie Og Maciel'a tutaj.Jak efektywnie testować. Przynajmniej kilka rad dał Luis Villa. Więcej na jego blog'u.Zasięg użycia google earth jest coraz bardziej imponujący. Można np. zobaczyć jakie zniszczenia stworzyły kopalnie odkrywkowe. Więcej w artykule na SlashDot'cie.Linux domination ? Po IBM'ie, Monachium itp. teraz Citroen się zdecydował na&lt;!--%kramer-post%--&gt;</description>
		<content:encoded><![CDATA[<p><a class="technorati-balloon" href="http://www.technorati.com/cosmos/search.html?url="><img src="http://static.technorati.com/images/bubble_h17.gif" class="technorati-balloon" alt="links from Technorati" style="border:0;" /></a>Zapomniałeś zapłacić rachunek ? Billreminder ci o tym przypomni. Więcej oraz przykładowe screenshot&#8217;y na stronie Og Maciel&#8217;a tutaj.Jak efektywnie testować. Przynajmniej kilka rad dał Luis Villa. Więcej na jego blog&#8217;u.Zasięg użycia google earth jest coraz bardziej imponujący. Można np. zobaczyć jakie zniszczenia stworzyły kopalnie odkrywkowe. Więcej w artykule na SlashDot&#8217;cie.Linux domination ? Po IBM&#8217;ie, Monachium itp. teraz Citroen się zdecydował na</p>
]]></content:encoded>
	</item>
</channel>
</rss>
