The state of trunk

Dan Mosedale dmose at
Fri Apr 30 19:25:35 UTC 2010

  On 4/30/10 11:52 AM, Mark Banner wrote:
> 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.
> 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 
> tinderbox page <>. 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.
> From a test I did earlier today at Andrew's suggestion, turning 
> "" to false fixes the failures. This 
> confirms his suspicion that the javascript engine is broken.
> Therefore I'm making the following proposals:
> - We temporarily set to false on the 
> trunk. Andrew hasn't got time to debug what is happening until after 
> 3.1rc1. We then set a 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.
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.
> - We wait to open the tree until: we have fixed linux bustages, 
> test_fuel.js and maybe one or two others.
> - 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, Bug 561333 
> <>).
> 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.
All of the above sounds good to me.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list