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" wrote:
> Hi Bill,
>
> Many thanks for working on the M-e10s. Does it means we can remove all
> these “test_ipc.html” mochitests? AFAI
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:
http://dxr.mozilla.org/mozilla-central/source/content/media/web
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] (l
Bill McCloskey 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 disabled for e10s. I
Aryeh Gregor writes:
> On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari 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 peopl
- Original Message -
> From: "Bobby Holley"
> To: "Bill McCloskey"
> Cc: "dev-platform"
> 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 make tests fail on e10s? I
> have some idea in my head of what t
> 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
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 nsITimer::TY
This is awesome! Great job getting us this far.
On Tue, Apr 8, 2014 at 2:28 PM, Bill McCloskey wrote:
> 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 might be, but I don't
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 s
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 t
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
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 I see that a separate discussion not really rel
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 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
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, usua
On 2014-04-08, at 11:40, Anne van Kesteren 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.e., attempting t
On Tue, Apr 8, 2014 at 11:24 AM, Brian Nicholson 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:
> https://groups.google.com/a/chromium.org/forum/#!forum/requ
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 experi
>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 wha
On Tuesday 2014-04-08 14:51 +0100, James Graham wrote:
> So, what's the minimum level of infrastructure that you think would
> be needed to go ahead with this plan? To me it seems like the
> current system already isn't working very well, so the bar for
> moving forward with a plan that would incre
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
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 wil
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
wrote:
If a bug is causing a test to fail intermittently, then that test
l
On 2014-04-08, 8:15 AM, Aryeh Gregor wrote:
On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari 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
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
wrote:
If a bug is causing a test to fail intermittently, then that test loses
value. It still has some value in th
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
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
On 07/04/14 11:49 AM, Aryeh Gregor wrote:
On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek 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 would not be able to
On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari 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
> intermittent test fa
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 emula
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
31 matches
Mail list logo
