<!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">
    On 4/30/10 11:52 AM, Mark Banner wrote:
    <blockquote cite="mid:4BDB2708.1060805@mozillamessaging.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      We're just starting the 3.1 beta 2 builds today. I was hoping that
      we would be able to reopen trunk today. However due to the state
      the tinderbox tree is in I'm not sure this is the right thing to
      do at this time.<br>
      <br>
      Over the last week or so, we've suffered a bit more than normal
      from bustages as a result of m-c changes. As a result, we still
      have a few bustages outstanding. The current ones are listed at
      the top of the <a moz-do-not-send="true"
        href="http://tinderbox.mozilla.org/Thunderbird/">tinderbox page</a>.
      Two of these are fixes that are required in m-c (linux bustages
      awaiting review, test_fuel.js failures has been looked at). A
      third (test_plugins.js) needs diagnosis, and the fourth is the
      mozmill failures. I also need to file one to pick up the new
      add-on manger work.<br>
      <br>
      From a test I did earlier today at Andrew's suggestion, turning
      "javascript.options.jit.chrome" to false fixes the failures. This
      confirms his suspicion that the javascript engine is broken.<br>
      <br>
      Therefore I'm making the following proposals:<br>
      <br>
      - We temporarily set javascript.options.jit.chrome to false on the
      trunk. Andrew hasn't got time to debug what is happening until
      after 3.1rc1. We then set a 3.1.next alpha blocker to investigate
      the failures and get it turned back on, hopefully way before the
      next alpha. This will allow development to continue in the interim
      period.<br>
    </blockquote>
    My one concern here is that this will mask us from noticing further
    trunk JIT breakage as it happens.  I think the strategy you propose
    is doable, but I'm wondering if we can do a bit better.  Are there
    bugs already filed for the two unknown breakages?  If so, how about
    dropping an email to Rob Sayre and asking if anyone on his team
    would have time to find the regression window and pursue them, since
    they're presumably JIT regressions which could effect Firefox as
    well.<br>
    <blockquote cite="mid:4BDB2708.1060805@mozillamessaging.com"
      type="cite"> - We wait to open the tree until: we have fixed linux
      bustages, test_fuel.js and maybe one or two others.<br>
      <br>
      - We restrict the tree to non-string changes until we have changed
      the l10n dashboard so that it gets 3.1 information from the
      comm-1.9.2 tree (to save confusing locales, <a
        moz-do-not-send="true"
        href="https://bugzilla.mozilla.org/show_bug.cgi?id=561333">Bug
        561333</a>).<br>
      <br>
      I think we should be able to get the tree open early next week. If
      those not working on 3.1rc1 blockers have time to investigate
      fixes for bustages, that would be a great help.<br>
    </blockquote>
    All of the above sounds good to me.<br>
    <br>
    Dan<br>
    <br>
  </body>
</html>