<!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 text="#000000" bgcolor="#ffffff">
    On 30/04/2010 20:25, Dan Mosedale wrote:
    <blockquote cite="mid:4BDB2EAF.30905@mozilla.org" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      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>
    FTR I've asked asuth to file the bug as he'll have more of the basic
    knowledge for what to point the team at.<br>
    <br>
    Standard8<br>
    <br>
  </body>
</html>