On 07/04/2014 23:13, Dave Hylands wrote:
Personally, I think that the more ways we can test for threading issues the
better.
It seems to me that we should do some amount of testing on single core and
multi-core.
Then I suppose the question becomes how many cores? 2? 4? 8?
Maybe we can
On (2014年04月08日 15:20), Gabriele Svelto wrote:
On 07/04/2014 23:13, Dave Hylands wrote:
Personally, I think that the more ways we can test for threading issues the
better.
It seems to me that we should do some amount of testing on single core and
multi-core.
Then I suppose the question
Hi,
Thanks for bringing up this issue.
One option (very, very painful, and even slower) would be a proper
device simulator which simulates both the CPU and the system hardware
(of *some* B2G phone). This would produce the most realistic result
with an emulator.
That is what the emulator
On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
What you're saying above is true *if* someone investigates the intermittent
test failure and determines that the bug is not important. But in my
experience, that's not what happens at all. I think many people treat
On 07/04/14 11:49 AM, Aryeh Gregor wrote:
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org wrote:
If a bug is causing a test to fail intermittently, then that test loses
value. It still has some value in that it can catch regressions that
cause it to fail permanently, but we
On 08/04/14 14:43, Andrew Halberstadt wrote:
On 07/04/14 11:49 AM, Aryeh Gregor wrote:
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org
wrote:
If a bug is causing a test to fail intermittently, then that test loses
value. It still has some value in that it can catch
On 2014-04-08, 9:51 AM, James Graham wrote:
On 08/04/14 14:43, Andrew Halberstadt wrote:
On 07/04/14 11:49 AM, Aryeh Gregor wrote:
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org
wrote:
If a bug is causing a test to fail intermittently, then that test loses
value. It still
On 2014-04-08, 8:15 AM, Aryeh Gregor wrote:
On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
What you're saying above is true *if* someone investigates the intermittent
test failure and determines that the bug is not important. But in my
experience, that's not what
On 08/04/14 15:06, Ehsan Akhgari wrote:
On 2014-04-08, 9:51 AM, James Graham wrote:
On 08/04/14 14:43, Andrew Halberstadt wrote:
On 07/04/14 11:49 AM, Aryeh Gregor wrote:
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org
wrote:
If a bug is causing a test to fail
We do talos testing on in-house machinery (iX machines with 4-core).
Not sure if that would trigger some of the issues you are hoping to be
caught.
In the future, we should be able to have some jobs run on different EC2
instance types. See https://bugzilla.mozilla.org/show_bug.cgi?id=985650
It
On 14-04-07 08:49 PM, Ehsan Akhgari wrote:
On 2014-04-07, 8:03 PM, Robert O'Callahan wrote:
When you say debug, you mean the emulator is running a FirefoxOS debug
build, not that the emulator itself is built debug --- right?
Given that, is it a correct summary to say that the problem is that
Hi,
Thanks for bringing up this issue.
One option (very, very painful, and even slower) would be a proper
device simulator which simulates both the CPU and the system hardware
(of *some* B2G phone). This would produce the most realistic result
with an emulator.
That is what the emulator
For the past few weeks, we've been working on requestAutocomplete, a
proposed standard for HTML forms that streamlines the checkout flow
for websites. Common payment and address form fields are shown in a
popup UI native to the browser, so all sites using the API will share
a common checkout
On Tue, Apr 8, 2014 at 11:24 AM, Brian Nicholson bnichol...@mozilla.com wrote:
There is currently no formal standard. A link to Chrome's
implementation:
http://www.chromium.org/developers/using-requestautocomplete. Some
discussion of the feature here:
On 2014-04-08, at 11:40, Anne van Kesteren ann...@annevk.nl wrote:
Related to this, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235
is awaiting our input I'm told. Background:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Apr/0010.html
In the spirit of ocean boiling
I see only two real goals for the proposed policy:
- ensure that module owners/peers have the opportunity to object to
any disable test decisions before they take effect
- set an expectation that intermittent orange failures are dealt with
promptly (dealt with first involves investigation, usually
On Tuesday 2014-04-08 11:41 -0700, Gavin Sharp wrote:
I see only two real goals for the proposed policy:
- ensure that module owners/peers have the opportunity to object to
any disable test decisions before they take effect
- set an expectation that intermittent orange failures are dealt with
On 4/8/2014 1:05 AM, Thomas Zimmermann wrote:
There are tests that instruct the emulator to trigger certain HW events.
We can't run them on actual phones.
To me, the idea of switching to a x86-based emulator seems to be the
most promising solution. What would be necessary?
Best regards
Thomas
On 2014-04-08, 3:15 PM, Chris Peterson wrote:
On 4/8/14, 11:41 AM, Gavin Sharp wrote:
Separately from all of that, we could definitely invest in better
tools for dealing with intermittent failures in general. Anecdotally,
I know chromium has some nice ways of dealing with them, for example.
But
Hi everyone,
Starting today, we have new mochitests that show up as M-e10s (1 2 3 4 5).
These are mochitests-plain running inside an e10s content process. Aside from
being in a separate process, they work pretty much the same as normal. Some
tests have been disabled for e10s. If you add a new
On Tue, Apr 08, 2014 at 02:28:02PM -0700, Bill McCloskey wrote:
Hi everyone,
Starting today, we have new mochitests that show up as M-e10s (1 2 3 4 5).
These are mochitests-plain running inside an e10s content process. Aside from
being in a separate process, they work pretty much the same
This is awesome! Great job getting us this far.
On Tue, Apr 8, 2014 at 2:28 PM, Bill McCloskey wmcclos...@mozilla.comwrote:
We have about 85% of mochitests-plain running right now.
Can you elaborate on the kinds of things that make tests fail on e10s? I
have some idea in my head of what they
Randell Jesup writes:
1) running on TBPL (AWS) the internal timings reported show the specific
test going from 30 seconds to 450 seconds with the patch.
2) on my local system, the test self-reports ~10 seconds, with or
without the patch.
Note: the timer in question is
Most of the work for this was done by Ted, Armen, Aki, and Mark Hammond.
Thanks guys!
And RyanVM! I knew I'd forget someone. Sorry.
-Bill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
- Original Message -
From: Bobby Holley bobbyhol...@gmail.com
To: Bill McCloskey wmcclos...@mozilla.com
Cc: dev-platform dev-platform@lists.mozilla.org
Sent: Tuesday, April 8, 2014 2:35:26 PM
Subject: Re: New e10s tests on tinderbox
Can you elaborate on the kinds of things that
Aryeh Gregor writes:
On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
What you're saying above is true *if* someone investigates the
intermittent test failure and determines that the bug is not
important. But in my experience, that's not what happens at
all. I
Bill McCloskey wmcclos...@mozilla.com wrote:
Starting today, we have new mochitests that show up as M-e10s (1 2 3 4 5).
These are mochitests-plain running inside an e10s content process. Aside from
being in a separate process, they work pretty much the same as normal. Some
tests have been
Thanks Dan. This looks to be contributing roughly half to our 30-45%
build speedup on Windows this month.
Daniel Minor wrote:
Hello,
Just a heads up that very soon we'll be removing jit-tests from the make check target[1]. The
tests have been split out into a separate test job on TBPL[2]
Hi Bill,
Many thanks for working on the M-e10s. Does it means we can remove all these
“test_ipc.html” mochitests? AFAIK these test cases are manually emulating an
e10s environment with some hacks.
Here is the list of test_ipc.html:
Not yet, because M-e10s is only running on Linux opt, and these test_IPC
tests run everywhere in opt and debug.
- Kyle
On Apr 8, 2014 6:58 PM, Shih-Chiang Chien sch...@mozilla.com wrote:
Hi Bill,
Many thanks for working on the M-e10s. Does it means we can remove all
these “test_ipc.html”
30 matches
Mail list logo
