<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 17/06/2010 09:19, 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>
    One minor issue I've just thought of. If mozilla-central does an API
    change which breaks canary, and we then check the fix into
    comm-central, then we'll temporarily break trunk.<br>
    <br>
    However, I think there's two options here: one is that we plan the
    trunk breakage so that once canary is green trunk will pick up the
    latest fix and rebuild, the other is that we provide a method for
    manually bumping the revision of trunk - i.e. I know this revision
    of mozilla-central will be green with the next revision of
    comm-central.<br>
    <br>
    I'll work that into the requirements later.<br>
    <br>
    Mark.<br>
  </body>
</html>