Canary System for trunk
Justin Wood (Callek)
callek at gmail.com
Sat Jun 19 02:14:37 UTC 2010
On 6/18/2010 6:20 PM, Dan Mosedale wrote:
> On 6/17/10 1:19 AM, Mark Banner wrote:
>> Based on the recent discussion
>> about a second set of builders / canary system. I've come up with a
>> spec of what we want it to do:
>> 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.
>> Hence, please provide thoughts/feedback here.
> Nicely put together. I like the goals & prioritization. I also like
> the automated updating of changesets.
> 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?
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).
> 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.
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
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.
There are ways around THAT a few times, but the "noise" and "repo bloat"
is not worth it imo.
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.
~Justin Wood (Callek)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning