Canary System for trunk

Justin Wood (Callek) callek at gmail.com
Fri Jun 18 01:48:03 UTC 2010


  (Client.py)>>Pull latest comm-central and update to a safe 
mozilla-central revision <<

*especially* if we make this default, it will depend on instrumentation 
a bit. What happens if --mozilla-repo is not m-c. Do we test for that, 
not support it, etc.  i.e. local clones, alternate project branches etc.

Then there is the question of what happens if there is a network failure 
between client.py and the service that hosts this setup. Do we assume 
m-c tip, no update, etc.

Last, do we care about potential extension alternatives 
(venkman/chatzilla) etc breakages/revs?

 >>When a mozilla-central changeset has all green builds, the changeset 
will be counted as "good".<<

Builds, Builds+Tests, Builds+Starred tests, other?

IOW what are we using to determine this "good" state exactly. A green 
build but thousands of busted tests is not necessarily good. Talos can 
have a MAJOR (>200% regression too) do we count talos in our infra here, 
if so "how"?

On 6/17/2010 4: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.
-- 
~Justin Wood (Callek)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20100617/faebd95a/attachment.html>


More information about the tb-planning mailing list