We plan to switch the Windows build machines to Visual Studio 2013 on the
Firefox 35 train.
Some benefits from this change:
* No more linker OOM crashes. VS2013 includes a 64-bit toolchain for 32-bit
builds, so the linker will no longer be limited to 4GB address space.
* The linker capacity open
On Thu, Aug 21, 2014 at 3:21 PM, Jonathan Griffin wrote:
> In summary, the sheriffs won't be backing out extra commits because of the
> coalescing, and it remains the sheriffs' job to backfill tests when they
> determine they need to do so in order to bisect a failure. We aren't
> placing any ex
On Thu, Aug 21, 2014 at 03:03:30PM -0700, Jonas Sicking wrote:
> What will be the policy if a test fails and it's unclear which push
> caused the regression?
You may have missed the main point that it's not "What will", but "What
is". It *is* already the case that tests are skipped.
Mike
It will be handled just like coalesced jobs today: sheriffs will
backfill the missing data, and backout only the offender.
An illustration might help. Today we might have something like this,
for a given job:
linux64-debug win7-debug osx8-debug
commit 1 pass pass
In general I think this sounds like a good idea. Not honoring autoplay
when on a mobile connection sounds good. I'm unsure what the best
behavior is on a mobile device when on a wifi connection, so I don't
feel strongly either way there.
On Thu, Aug 21, 2014 at 11:16 AM, Wesley Johnston wrote:
>>
What will be the policy if a test fails and it's unclear which push
caused the regression? Is it the sheriff's job, or the people who
pushed's job to figure out which push was the culprit and make sure
that that push gets backed out?
I.e. if 4 pushes land between two testruns, and we see a regress
> In general, I'm in favour of not autoplaying at all on mobile devices.
I think I was just trying to address the spec's statement of overriding when
not desired. I don't want to punish sites that are reading that and trying to
be good citizens. For instance, elements are actually a good solutio
Hey Martin,
This is a good idea, and we've been thinking about approaches like
this. Basically, the idea is to run tests that "(nearly) always pass"
less often. There are currently some tests that fit into this category,
like dom level0,1,2 tests in mochitest-plain, and those are
time-consu
Hi Wes,
On 2014-08-21, 10:29 AM, Wesley Johnston wrote:
Summary: We've had some complaints at times about videos autoplaying on mobile devices
when sites request autoplay. We should be more mindful of users and try to avoid using
data if they don't want it. Sites should be doing this for us, b
Thanks Ed. To paraphrase, no test coverage is being lost here, we're
just being a little more deliberate with job coalescing. All tests will
be run on all platforms (including debug tests) on a commit before a
merge to m-c.
Jonathan
On 8/21/2014 9:35 AM, Ed Morley wrote:
I think much of the
On 8/21/14 9:35 AM, Ed Morley wrote:
4) When merging into mozilla-central, sheriffs ensure that all jobs are
green - including those that got coalesced and those that are only
scheduled periodically (eg non-unified & PGO builds are only run every 3
hours). (This is a fairly manual process current
Summary: We've had some complaints at times about videos autoplaying on mobile
devices when sites request autoplay. We should be more mindful of users and try
to avoid using data if they don't want it. Sites should be doing this for us,
but we've encountered pages where that is not the case. I'm
On 20/08/14 17:37, Jonas Sicking wrote:
It would however be really cool if we were able to pull data on which
tests tend to fail in a way that affects all platforms, and which ones
tend to fail on one platform only.
Here's a potential project that might help. For all of the trees
(probably tr
I think much of the pushback in this thread is due to a misunderstanding
of some combination of:
* our current buildbot scheduling
* the proposal
* how trees are sheriffed and merged
To clarify:
1) We already have coalescing [*] of jobs on all trees apart from try.
2) This coalescing means tha
I want to pass a out parameter with render, but don't know how to do that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
- Milan
On Aug 21, 2014, at 10:12 , Chris AtLee wrote:
> On 17:37, Wed, 20 Aug, Jonas Sicking wrote:
>> On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert wrote:
>>> I have been asked in the past if we really need to run WebGL tests on
>>> Android, if they have coverage on Desktop platforms.
>>
On 17:37, Wed, 20 Aug, Jonas Sicking wrote:
On Wed, Aug 20, 2014 at 4:24 PM, Jeff Gilbert wrote:
I have been asked in the past if we really need to run WebGL tests on Android,
if they have coverage on Desktop platforms.
And then again later, why B2G if we have Android.
There seems to be enoug
In other works, is there any way to decode a local image to
nsCOMPtr synchronously, the image is a url like
url("data:image/png;base64,iVBORw0KGgoNSUhEUgAAARQAAABgCAYAAADctI0aAAAITElEQVR4nO2dy5HbOhBFGcvEoUC81aaZgbfMwlVMgysHoRC8Zhp6iw...")
___
de
I want to draw images in a dynamic way, and the image are transparent and have
backgrounds, so I don't want the background draw and the image draw are
separate so that the I will see flicking.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
I was styling a xul tree cell with
treechildren::-moz-tree-image(richCol) {
list-style-image:
url("data:image/png;base64,iVBORw0KGgoNSUhEUgAAARQAAABgCAYAAADctI0aAAAITElEQVR4nO2dy5HbOhBFGcvEoUC81aaZgbfMwlVMgysHoRC8Zhp6iwfQl80GCOpjSVPnVLFq+AHQANEXDdCCuw4AAD6Nvu8vZjb
20 matches
Mail list logo
