In bug# 773120, there was some concern that turning off 10.5 testing would have the side effect of also turning off all our 32bit testing. 1) This bug to track setting up tests for Firefox running in 32bit mode on osx10.6 machines in order to keep some form of 32bit test coverage. 2) This is in addition to the existing tests in 64bit mode on osx10.6. From irc, its unknown if we need a different 32-bit-only install of osx10.6, or if we can use the same one install of osx10.6 to run both 64bit Firefox tests and 32bit Firefox tests. (latter is preferred, easier for pool management). 3) This would be for FF17, FF18 and beyond...

This can be deprioritized a bit as there are only a very small handful of Mac models that are 32-bit (mostly from early to mid 2006). These Macs are no longer supported by Apple in 10.7 or 10.8, and we only support them on 10.6. I'd expect that problems on these platforms will become obvious in our test population. If users run into issues caused by setting the 32-bit pref in-app, we can always advise otherwise. I think we can get this going on a bit longer of a timeline given other priorities.

Maybe a couple of weeks until we ship a (half) completely untested binary that may or may not even start up to our beta audience, nine until we ship one to our release audience, how long a timeline were you figuring on?

We're going to be testing Firefox running in 32bit mode as part of b1 QA sign-off. Still discussing with joduinn how/when to prioritize getting these tests up and running.

I've integrated a regression test into our MozTrap manual testsuite which will be run against all OSX versions for all Beta/Release builds going forward. For your viewing pleasure: https://moztrap.mozilla.org/manage/case/2526/ FWIW, we started running this test with Firefox 16.0b6 and onward.

We're talking about doubling the current test load on the Snow Leopard machines here. I will note that our pool of machines (r4 minis) for Snow Leopard (10.6) is finite: we cannot buy more. We could re-purpose some r4s that are currently running Lion (10.7), but only at the expense of Lion wait times. For reference, job counts and wait times for both platforms for last night were as follows: snowleopard-r4: 4763 0: 3832 80.45% 15: 332 6.97% 30: 184 3.86% 45: 124 2.60% 60: 53 1.11% 75: 67 1.41% 90+: 171 3.59% lion: 4755 0: 3517 73.96% 15: 452 9.51% 30: 129 2.71% 45: 122 2.57% 60: 99 2.08% 75: 115 2.42% 90+: 321 6.75%

(In reply to Chris Cooper [:coop] from comment #5) > We're talking about doubling the current test load on the Snow Leopard > machines here. I will note that our pool of machines (r4 minis) for Snow > Leopard (10.6) is finite: we cannot buy more. We could re-purpose some r4s > that are currently running Lion (10.7), but only at the expense of Lion wait > times. Can we run this on a subset of branches? Maybe Aurora/Beta?

Doesn't seem like this will be ready before we ship 17, moving tracking to 18 to continue to drive this to completion. Email sent on 11/7 asking for feedback on comment 6 - still waiting to hear back.

Found in triage: Any updated thoughts on the relative merits of this after 7 months?

FWIW, QA still checks 32-bit mode Firefox on Mac OSX (all versions) as part of it's Beta Regression suite.

Unless someone from relman overrules me here, we don't have the r4 mini capacity to turn on more 10.6 testing, and we do have some (beta) release testing coverage from QA.