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 
>> <http://groups.google.com/group/tb-planning/browse_frm/thread/7cd3e8ab756f910e#> 
>> about a second set of builders / canary system. I've come up with a 
>> spec of what we want it to do:
>>
>> https://wiki.mozilla.org/Thunderbird/Infrastructure/Canary_System
>>
>> 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 
low priority.

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...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20100618/46b97215/attachment.html>


More information about the tb-planning mailing list