<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    In this email, I'm talking about the trunk that is comm-central with
    mozilla-central, these builds are now identified as "3.4a1pre".<br>
    <br>
    First, if you haven't seen already, --disable-ipc and
    --disable-libxul are now obsolete. We've just enabled IPC on the
    Thunderbird builds, so if you're getting build errors, make sure
    you're fully up to date.<br>
    <br>
    As of earlier today, we have no builders building comm-central and
    mozilla-central, we're hoping to fix that sometime in the next 24
    hours. These builders will report to a "ThunderbirdTrunk" tree:
    <a class="moz-txt-link-freetext" href="http://tinderbox.mozilla.org/showbuilds.cgi?tree=ThunderbirdTrunk">http://tinderbox.mozilla.org/showbuilds.cgi?tree=ThunderbirdTrunk</a>
    and there will be one added on tbpl as well. This means the old
    "Thunderbird" tinderbox tree will become obsolete.<br>
    <br>
    Notes:<br>
    <ul>
      <li>Our development focus is on Thunderbird 3.3, therefore:</li>
      <ul>
        <li>The Miramar tree (comm-central with mozilla-2.0) is the one
          to be used to determine the current tree state.</li>
        <li>Patches landing in comm-central shouldn't attempt to avoid
          breaking ThunderbirdTrunk unless really necessary (ask drivers
          if you're not sure).</li>
        <li>ThunderbirdTrunk may be broken by patches landing in
          mozilla-central.</li>
        <ul>
          <li>If that happens, it is not a priority for these to be
            fixed, so bustage may go for a few days or more without
            being resolved.</li>
        </ul>
      </ul>
      <li>There will be no nightlies for the ThunderbirdTrunk tree for a
        short while at least (as mentioned previously on this list).</li>
      <li>If the complexity of handling Miramar and ThunderbirdTrunk
        both from comm-central becomes significant, then drivers will
        work out an appropriate way forward.</li>
      <li>I'm intentionally not adding 3.4a1pre to addons.mozilla.org at
        this time. This caused us issues before, I'll discuss with
        drivers next week, and we'll reconsider it in any case when we
        start generating nightly builds.<br>
      </li>
    </ul>
    Mark.<br>
  </body>
</html>