<!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/18/2010 6:20 PM, Dan Mosedale wrote:
<blockquote cite="mid:4C1BF120.3090806@mozilla.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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>
</blockquote>
<br>
No strong feeling, but I do like "TBCanary" and "Thunderbird" make
sense (with links to a brief doc on the diff for sake of argument at
the top of each tinderbox page). The point that matters is
TbUntested is not exactly untested, and sounds more like a stage
than a canary. (i.e. can completely ignore it even when its fully
burning).<br>
<br>
<blockquote cite="mid:4C1BF120.3090806@mozilla.org" type="cite"> 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>
</blockquote>
<br>
Even if I supported this (I don't -- I think _any_ solution that
wants checkin to RCS needs to be external RCS to comm-central), IFF
it was included in client.py we'd need a solution that restarted
client.py when it changes. Which I have filed as a bug a long while
ago, but was deemed low priority.<br>
<br>
The reasoning is that you have, client.py at a known good rev
locally; remotely a newer known good rev is added. You run client.py
co; comm-central updates, with that new known-good-rev, including a
fix that would otherwise break c-c without the newer m-c. Client.py
that is running is the OLD client.py (not the new one imported with
this updated c-c) all of a sudden we go to pull m-c, but we already
have the known good rev.... too bad we'll break build later until
the next time you pull.<br>
<br>
There are ways around THAT a few times, but the "noise" and "repo
bloat" is not worth it imo.<br>
<br>
At a worse case we should create a new repo just for this (if its
not a web service) and tell client.py about it, pull it and if repo
is non-existant or 404 for some reason, we use tip.<br>
<br>
-- <br>
~Justin Wood (Callek)<br>
</body>
</html>