<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 17/06/2010 09:19, 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>
One minor issue I've just thought of. If mozilla-central does an API
change which breaks canary, and we then check the fix into
comm-central, then we'll temporarily break trunk.<br>
<br>
However, I think there's two options here: one is that we plan the
trunk breakage so that once canary is green trunk will pick up the
latest fix and rebuild, the other is that we provide a method for
manually bumping the revision of trunk - i.e. I know this revision
of mozilla-central will be green with the next revision of
comm-central.<br>
<br>
I'll work that into the requirements later.<br>
<br>
Mark.<br>
</body>
</html>