On Tuesday, May 10, 2016 at 8:07:05 PM UTC-7, Mike Hommey wrote:
> On Tue, May 10, 2016 at 10:58:25PM -0400, Lawrence Mandel wrote:
> > On Fri, May 6, 2016 at 6:43 AM, Xidorn Quan wrote:
> >
> > > On Fri, May 6, 2016 at 8:24 PM, Mike Hommey wrote:
> > >
> > > > On Fri, May 06, 2016 at 06:01:12PM
Hello team,
We're now scheduling two talos jobs for every PGO build on fx-team [1]
and m-i.
This is to help reduce the time it takes to find PGO specific
regressions for these two branches.
If you see any issues falling out of this please file it under
Testing::General and CC me.
This is
What impact will this have on machine capacity? The Windows and Mac testers are
already highly overwhelmed. Try jobs are often delayed by several hours, which
I think is a major concern.
(I can't remember if we have a separate pool for Talos testers [on Try].)
> On May 12, 2016, at 05:01, Armen
IIUC, we have PGO builds running on fx-team and m-i every 6 hours.
This only affects Linux x64 and Windows (not Mac).
The test pools are shared between all repositories.
This entails 14 extra jobs for Windows XP and Windows 8.
This entails 16 extra jobs for Windows 7.
This is equivalent to two m
On 5/12/2016 10:51 AM, Armen Zambrano G. wrote:
IIUC, we have PGO builds running on fx-team and m-i every 6 hours.
This only affects Linux x64 and Windows (not Mac).
The test pools are shared between all repositories.
This entails 14 extra jobs for Windows XP and Windows 8.
This entails 16 extra
My apologies. I looked at the "default" value rather than the project
specific cadence.
https://dxr.mozilla.org/build-central/source/buildbot-configs/mozilla/project_branches.py#20
On 2016-05-12 11:12 AM, Ryan VanderMeulen wrote:
On 5/12/2016 10:51 AM, Armen Zambrano G. wrote:
IIUC, we have P
Hello,
Given all the discussion around SSE[2] lately, I was curious as to
whether we had made any plans to update Windows users that are running
32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows
builds. The 64-bit Windows builds do use SSE2, since that's a baseline
requirement for
How would we handle going from Program Files (x86) to Program Files?
Just leave the install directory as-is for updates?
On 5/12/2016 11:45 AM, Ted Mielczarek wrote:
Hello,
Given all the discussion around SSE[2] lately, I was curious as to
whether we had made any plans to update Windows users
We would have to since other users on the system can have shortcuts
pointing to the original location. We've also performed some minimal
testing that this is fine when we looked into this a couple of years ago.
Robert
On Thu, May 12, 2016 at 8:53 AM, Ryan VanderMeulen wrote:
> How would we han
The DLL Interceptor has some problems on 64-bit Windows 10 that we'd
probably want to fix before doing this. See bug 1240977.
On 5/12/2016 9:45 AM, Ted Mielczarek wrote:
Hello,
Given all the discussion around SSE[2] lately, I was curious as to
whether we had made any plans to update Windows us
The good news is that jseward has been doing regular TSan runs with
xpcshell tests and fixing reported races since last year. Bug 929478
is the tracking bug. The number of reported races is much lower than
it used to be, and Telemetry code is the single biggest remaining
offender, which is why jsew
On Thursday 2016-05-12 11:45 -0400, Ted Mielczarek wrote:
> requirement for x86-64 processors, and the overall performance should
> generally be better (modulo memory usage, I'm not sure if we have an
> exact comparison). Additionally 64-bit builds are much less likely to
> encounter OOM crashes du
Do you have thoughts on how we'll be able to serve the users the correct
build if we have to base the decision on plugins they may have or other
information that's not in the update ping? We can already detect 32-bit
builds on 64-bit Windows through the build target, but information about
plugi
I suspect we'd want to add some extra token like "it's ok to update this
32-bit build to a 64-bit build", and have all the gating logic live on
the client-side. Odds are if we want to change the criteria we'd have to
change the client anyway.
-Ted
On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wr
On Thu, May 12, 2016, at 12:22 PM, L. David Baron wrote:
> On Thursday 2016-05-12 11:45 -0400, Ted Mielczarek wrote:
> > requirement for x86-64 processors, and the overall performance should
> > generally be better (modulo memory usage, I'm not sure if we have an
> > exact comparison). Additionally
This is a slight change from the current model where we purposely make
the client very dumb, and make the decision on the server (to minimize
the possibility of client-side bug making updates impossible). However,
this doesn't seem like a case where we could get somebody stuck very
easily, and
Do we need this criteria?
RAM - Does it hurt to move an instance that has <4GB?
NPAPI - We've announced that we'll remove support this year [1]. Should we
just wait until we do? Do we have a solution for Flash on Win64 that makes
this viable?
Lawrence
[1]
https://blog.mozilla.org/futurereleases/
Hi, this is an "intent to align with the spec" PSA.
The MediaCapture and Streams spec [1] says that sites requesting both
camera and microphone at the same time, must get both or nothing (in the
form of an error).
Firefox's permission doorhanger violates this invariant by offering
users the
Flash installs the 32-bit and 64-bit plugin versions side by side
already (in System32 and SysWOW64, respectively), so I don't think
that's an issue here.
-Ryan
On 5/12/2016 3:38 PM, Lawrence Mandel wrote:
Do we need this criteria?
RAM - Does it hurt to move an instance that has <4GB?
NPAPI
Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit
Firefox. Streaming video services will likely move their Firefox users
from Silverlight to Widevine this year, so Silverlight usage will
decline by EOY.
On 5/12/16 1:10 PM, Ryan VanderMeulen wrote:
Flash installs the 32-
On Thu, May 12, 2016 at 12:48 PM, Jan-Ivar Bruaroey wrote:
> Our original intent behind those choices was to let users join a video
> conference as an "audio only" participant. Unfortunately, sites don't expect
> this behavior and often don't work right when the track is missing.
This part should
Lawrence Mandel writes:
> Do we need this criteria?
>
> RAM - Does it hurt to move an instance that has <4GB?
Yes. OOM will be more common with 64-bit builds on systems with
less RAM because 64-bit builds use more memory.
___
dev-platform mailing list
Last time I checked we saw something like a 35% increase in overhead on
AWSY going from 32-bit to 64-bit Firefox on 64-bit Windows, so yes there is
a significant impact.
On the other hand you no-longer run into the
OOM-because-of-address-space-exhaustion and
OOM-because-we-can't-find-a-one-meg-chu
On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinson wrote:
> Lawrence Mandel writes:
>
> > Do we need this criteria?
> >
> > RAM - Does it hurt to move an instance that has <4GB?
>
> Yes. OOM will be more common with 64-bit builds on systems with
> less RAM because 64-bit builds use more memory.
>
On Thursday 2016-05-12 15:33 -0700, Kyle Huey wrote:
> On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinson wrote:
>
> > Lawrence Mandel writes:
> >
> > > Do we need this criteria?
> > >
> > > RAM - Does it hurt to move an instance that has <4GB?
> >
> > Yes. OOM will be more common with 64-bit build
On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote:
> Lawrence Mandel writes:
>
> > Do we need this criteria?
> >
> > RAM - Does it hurt to move an instance that has <4GB?
>
> Yes. OOM will be more common with 64-bit builds on systems with
> less RAM because 64-bit builds use m
On 5/12/16 4:41 PM, Jonas Sicking wrote:
This part should be fixable by creating a video stream which just
contains black (or a "anonymous user" icon or some such).
In theory yes, but I don't think the existing UX is salvageable when
mapped to mute (nowhere to unmute, and site now thinks it ha
On 5/12/16 2:48 PM, Jan-Ivar Bruaroey wrote:
Our original intent behind those choices was to let users join a video
conference as an "audio only" participant. Unfortunately, sites don't
expect this behavior and often don't work right when the track is missing.
Fixing sites sounds good.
Are the
On inbound (and soon central), for Chromium MessageLoops that belong to an
XPCOM thread (either the main thread, or created via the thread manager)
posting tasks now calls through to the underlying XPCOM thread's dispatch
implementation. This could cause subtle breakage because event ordering
has
29 matches
Mail list logo
