<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 6/17/10 1:19 AM, Mark Banner wrote:
<blockquote cite="mid:4C19DAA6.5010501@mozillamessaging.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Based on the <a moz-do-not-send="true"
href="http://groups.google.com/group/tb-planning/browse_frm/thread/7cd3e8ab756f910e#">recent
discussion</a> about a second set of builders / canary system.
I've come up with a spec of what we want it to do:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://wiki.mozilla.org/Thunderbird/Infrastructure/Canary_System">https://wiki.mozilla.org/Thunderbird/Infrastructure/Canary_System</a><br>
<br>
At this stage, I'm just trying to come up with a list of
aims/basic design features to check that we've got everything that
we want from it covered. Once we've agreed on that, then we can
start thinking about the implementation.<br>
<br>
Hence, please provide thoughts/feedback here.<br>
</blockquote>
Nicely put together. I like the goals & prioritization. I also
like the automated updating of changesets.<br>
<br>
I would suggest making the names more explicit, as it feels to me
like the current proposed names are likely to lead to confusion.
Maybe TbKnownGood and TbUntested?<br>
<br>
As far as keeping old data to support regression hunting, would it
work to automatically check in the most recent known good
mozilla-central tag to comm-central client.py? That way any given
client.py revision would have the appropriate working
mozilla-central revision encoded in it.<br>
<br>
Dan<br>
<br>
</body>
</html>