<!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">
    (Client.py)>>Pull latest comm-central and update to a safe
    mozilla-central revision
    <<<br>
    <br>
    *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.<br>
    <br>
    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.<br>
    <br>
    Last, do we care about potential extension alternatives
    (venkman/chatzilla) etc breakages/revs?<br>
    <br>
    >>When a mozilla-central changeset has all green builds, the
    changeset will be counted as "good".<<<br>
    <br>
    Builds, Builds+Tests, Builds+Starred tests, other?<br>
    <br>
    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"?<br>
    <br>
    On 6/17/2010 4: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>
    -- <br>
    ~Justin Wood (Callek)<br>
  </body>
</html>